A memory object management method, device, equipment and readable storage medium
By binding Slab pages and object types in memory object management methods, the problem of cross-cache type obfuscation attacks in the Linux kernel is solved, the stability and security of memory object types are achieved, and the security risks of the system are reduced.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- NEW H3C TECH CO LTD
- Filing Date
- 2026-04-29
- Publication Date
- 2026-07-21
AI Technical Summary
In existing technologies, the Linux kernel's Slab allocator is vulnerable to cross-cache type obfuscation attacks in memory object management, resulting in high system security risks.
In the memory object management method, in response to a memory object allocation request, the object type is determined. If the target Slab page does not exist, the Slab page of the released physical page is bound and its mapping relationship is established to ensure the consistency of memory object types and avoid different types of memory objects sharing the same virtual address.
It effectively reduces the risk of cross-cached type obfuscation attacks, ensures the stability and security of memory object types, and improves the efficiency and security of memory management.
Smart Images
Figure CN122132326B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of memory object management technology, and in particular to a memory object management method, apparatus, device and readable storage medium. Background Technology
[0002] To support the operation of various kernel subsystems such as file systems, network protocol stacks, and device drivers, the Linux kernel widely uses the Slab allocator for efficient management of memory objects.
[0003] In existing technologies, kernel virtual address allocation is primarily implemented based on the kernel physimap, where a slab page represents a virtual address that corresponds to one or more contiguous physical pages. Because virtual addresses and physical addresses are linearly mapped and physical pages can be globally reused, when a cache (kmem_cache) releases a slab page with no memory objects occupying it, the slab allocator will reclaim the corresponding physical page from the page allocator. The page allocator may then reassign this physical page to other cache types.
[0004] Attackers can exploit the above mechanism to induce the kernel to release Slab pages containing sensitive memory objects, and then allocate the corresponding physical pages to different types of memory objects carrying malicious data through other allocation paths. This causes different types of memory objects to share the same virtual address, resulting in type obfuscation. Such obfuscation can be used by attackers for privilege escalation, bypassing security mechanisms, and other attacks, posing an extremely high risk to system security. Therefore, the current method is vulnerable to cross-cache type obfuscation attacks. Summary of the Invention
[0005] The purpose of this application is to provide a memory object management method, apparatus, device, and readable storage medium, which can effectively reduce the risk of cross-cache type obfuscation attacks. The specific technical solution is as follows:
[0006] In a first aspect, embodiments of this application provide a memory object management method, the method comprising:
[0007] In response to a memory object allocation request, determine the first object type indicated by the memory object allocation request;
[0008] If the target Slab page does not exist, determine the Slab page that has released physical pages and is bound to the first object type, and use it as the first Slab page; wherein, the target Slab page contains a free memory object of the first object type and has not released physical pages;
[0009] After allocating the first physical page, a mapping relationship is established between the first physical page and the first Slab page, and a free memory object is returned based on the first object type to initialize the first physical page.
[0010] Optionally, before determining that a physical page has been released and a Slab page bound to the first object type has been used as the first Slab page if the target Slab page does not exist, the method further includes:
[0011] Based on the Slab entries in the metadata virtual address area, detect whether the target Slab page exists in the object data virtual address area; where a Slab entry represents the object type bound to the corresponding Slab page in the object data virtual address area;
[0012] If the target Slab page does not exist, determining the Slab page that has been released from the physical page and bound to the first object type as the first Slab page includes:
[0013] If the target Slab page does not exist in the object data virtual address area, the first Slab page is determined from the Slab pages of the released physical pages; wherein, the Slab entry corresponding to the first Slab page in the metadata virtual address area represents the binding of the first object type.
[0014] Optionally, the method further includes:
[0015] If the target Slab page does not exist in the object data virtual address area, and there is no Slab page that has been released and bound to the first object type, a second Slab page is created in the object data virtual address area, and a Slab entry corresponding to the second Slab page is created in the metadata virtual address area.
[0016] After allocating the second physical page, a mapping relationship between the second physical page and the second Slab page is established. The free memory object obtained by initializing the second physical page based on the first object type is returned, and the Slab entry corresponding to the second Slab page is updated.
[0017] Optionally, the method further includes:
[0018] When all memory objects in the first Slab page are in an idle state, the mapping relationship between the first Slab page and the first physical page is deleted, the first physical page is released asynchronously, and the page table buffer is refreshed.
[0019] Optionally, the asynchronous release of the first physical page and the flushing of the page table buffer include:
[0020] A release task to release the first physical page and a refresh task to refresh the page table buffer are sent to the task queue corresponding to the kernel thread, so that the kernel thread refreshes the page table buffer and releases physical pages in batches according to the tasks in the task queue.
[0021] Optionally, after determining the first object type indicated by the memory object allocation request in response to the memory object allocation request, the method further includes:
[0022] If a target Slab page exists, decode the pointers to the free memory objects to be allocated in the free list of the target Slab page;
[0023] Perform alignment mask verification on the decoding result, and / or verify whether the decoding result is within the virtual address represented by the target Slab page;
[0024] If the verification result is normal, return the decoding result; if the verification result is abnormal, issue an alarm.
[0025] Optionally, the method further includes:
[0026] In response to a statistics query request for the second object type, return the number of Slab pages that have been released and bound to the second object type.
[0027] Secondly, embodiments of this application provide a memory object management device, the device comprising:
[0028] The first object type determination module is used to determine the first object type indicated by the memory object allocation request in response to the memory object allocation request;
[0029] The first Slab page determination module is used to determine, if the target Slab page does not exist, a Slab page that has released physical pages and is bound to the first object type as the first Slab page; wherein, the target Slab page contains a free memory object of the first object type and has not released physical pages;
[0030] The first response module is used to establish a mapping relationship between the first physical page and the first Slab page after allocating the first physical page, and return a free memory object obtained by initializing the first physical page based on the first object type.
[0031] Optionally, the device further includes:
[0032] The detection module is used to determine whether a target Slab page exists in the object data virtual address area based on the Slab entries in the metadata virtual address area before determining that a released physical page and a Slab page bound to the first object type are used as the first Slab page if the target Slab page does not exist. Herein, a Slab entry represents the object type bound to the Slab page corresponding to the Slab page in the object data virtual address area.
[0033] The first Slab page determination module is specifically used to determine the first Slab page from the Slab pages of the released physical pages if the target Slab page does not exist in the object data virtual address area; wherein, the Slab entry corresponding to the first Slab page in the metadata virtual address area represents the binding of the first object type.
[0034] Optionally, the device further includes:
[0035] The second response module is used to create a second Slab page in the object data virtual address area and create a Slab entry corresponding to the second Slab page in the metadata virtual address area if the target Slab page does not exist in the object data virtual address area and there is no Slab page that has been released and bound to the first object type.
[0036] After allocating the second physical page, a mapping relationship between the second physical page and the second Slab page is established. The free memory object obtained by initializing the second physical page based on the first object type is returned, and the Slab entry corresponding to the second Slab page is updated.
[0037] Optionally, the device further includes:
[0038] The release module is used to delete the mapping relationship between the first Slab page and the first physical page when all memory objects in the first Slab page are in an idle state, and to release the first physical page asynchronously, as well as refresh the page table buffer.
[0039] Optionally, the release module is specifically used to send a release task to release the first physical page and a refresh task to refresh the page table buffer to the task queue corresponding to the kernel thread, so that the kernel thread refreshes the page table buffer and releases physical pages in batches according to the tasks in the task queue.
[0040] Optionally, the device further includes:
[0041] The third response module is used to, in response to a memory object allocation request, determine the first object type indicated by the memory object allocation request, and if a target Slab page exists, decode the pointers to free memory objects to be allocated in the free list of the target Slab page.
[0042] Perform alignment mask verification on the decoding result, and / or verify whether the decoding result is within the virtual address represented by the target Slab page;
[0043] If the verification result is normal, return the decoding result; if the verification result is abnormal, issue an alarm.
[0044] Optionally, the device further includes:
[0045] The statistics query module is used to respond to a statistics query request for the second object type and return the number of Slab pages that have been released and bound to the second object type.
[0046] Thirdly, embodiments of this application provide an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;
[0047] Memory, used to store computer programs;
[0048] When a processor executes a program stored in memory, it implements any of the steps described above.
[0049] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the steps described above.
[0050] Fifthly, embodiments of this application provide a computer program product containing instructions that, when run on a computer, cause the computer to perform any of the methods described above.
[0051] Beneficial effects of the embodiments in this application:
[0052] The memory object management method provided in this application embodiment, in response to a memory object allocation request, determines the first object type indicated by the memory object allocation request; if no target Slab page exists, it determines a Slab page that has released physical pages and is bound to the first object type, and uses it as the first Slab page; the target Slab page contains a free memory object of the first object type and has not released physical pages; after allocating the first physical page, it establishes a mapping relationship between the first physical page and the first Slab page, and returns a free memory object obtained by initializing the first physical page based on the first object type.
[0053] Based on the memory object management method provided in this application, Slab pages are bound to object types. For any Slab page, even if the physical page historically mapped to that Slab page is reclaimed, the type of the memory objects in that Slab page remains unchanged after mapping to a new physical page. This avoids, to a certain extent, different types of memory objects sharing the virtual address represented by the same Slab page, effectively reducing the risk of cross-cache type obfuscation attacks.
[0054] Of course, implementing any product or method of this application does not necessarily require achieving all of the advantages described above at the same time. Attached Figure Description
[0055] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other embodiments can be obtained based on these drawings.
[0056] Figure 1 A flowchart illustrating a memory object management method provided in an embodiment of this application;
[0057] Figure 2 A flowchart illustrating another memory object management method provided in an embodiment of this application;
[0058] Figure 3 This is a schematic diagram of the structure of a memory object management device provided in an embodiment of this application;
[0059] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation
[0060] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art based on this application are within the scope of protection of this application.
[0061] To facilitate understanding, the terminology used in this application will be introduced first.
[0062] Slub: The mainstream Slab allocator implementation in the Linux kernel, which removes the queued metadata structure of the old Slab allocator to improve allocation and recycling performance.
[0063] CONFIG_VIRTUAL_SLUB: A kernel configuration option. When enabled, the SLUB allocator manages memory objects from a dedicated high-end virtual address region and ensures that the virtual address is bound to only the initial cache type during its lifetime, thus defending against cross-cache type obfuscation attacks.
[0064] kmem_cache: A cache description structure in the Slab allocator used to manage information such as the allocation, release, and object constructors of memory objects of a specific size or type.
[0065] Cross-cache attack: A cross-cache attack, also known as a cross-cache type obfuscation attack, is a security attack technique that involves releasing the Slab page containing the target memory object and then using other allocation requests to map the same physical page to different types of caches, thereby achieving cross-cache type obfuscation and subsequent exploitation.
[0066] Physmap: The kernel linear mapping region, which provides a one-to-one direct mapping from virtual addresses to physical memory, and is often used to directly map physical pages.
[0067] struct slab: Describes the metadata structure of a single Slab instance, including information such as the object's free list, its cache, the number of objects, and its order.
[0068] virt_to_slab() / slab_to_virt(): Kernel functions used to perform arithmetic computation mapping or reverse mapping between an object's virtual address and its corresponding Slab metadata.
[0069] alloc_slab_page(): An internal function of Slub used to allocate new Slab pages. In CONFIG_VIRTUAL_SLUB mode, it is extended to support the allocation of kmem_cache context and metadata pages.
[0070] GFP Flags: Page allocation flags that control memory allocation behavior, such as whether blocking is allowed or whether to use a spare memory pool.
[0071] PTE (Page Table Entry): A page table entry responsible for the final mapping of virtual addresses to physical pages.
[0072] TLB Flush (Translation Lookaside Buffer Flush): Flushes the page table buffer, causing modified or invalidated virtual address mappings to be synchronously invalidated on all processors.
[0073] Kthread: Kernel thread, runs in kernel space, and can be used as a background task to handle delayed or batch operations.
[0074] vslub_tlbflush_worker: A new kernel worker thread introduced in CONFIG_VIRTUAL_SLUB mode, used to perform PTE cleanup and TLB flushing of Slab pages in batches before releasing the physical pages.
[0075] Freepointer: A pointer field in the free list of objects within a slab page, pointing to the next free object.
[0076] freelist_ptr_decode(): An internal function of Slub, used to decode the free list pointer and verify its validity to prevent the free list pointer from being tampered with.
[0077] deallocated_pages: Allocation pages, a newly added sysfs attribute, displays the number of pages whose virtual addresses are still occupied but whose physical pages have been released (i.e., Slab pages), used for monitoring and debugging the behavior of CONFIG_VIRTUAL_SLUB.
[0078] The existing memory object allocation process includes the following steps:
[0079] When the Slub allocator receives a memory object allocation request, it can determine a free memory object from the existing Slab pages in the kmem_cache, or allocate a new Slab page and obtain a free memory object. Then, it obtains the virtual address from the kernel linear mapping area, with a one-to-one correspondence between physical pages and virtual addresses. Subsequently, when all memory objects in a Slab page are free, the corresponding physical page is returned to the page allocator. The page allocator can then allocate this physical page to any other allocation request, causing the same virtual address to point to a different type of memory object, resulting in type confusion.
[0080] To effectively reduce the risk of cross-cache type obfuscation attacks, this application provides a memory object management method, apparatus, device, and readable storage medium. The memory object management method provided in this application is described below.
[0081] In one embodiment, a memory object management method includes: responding to a memory object allocation request, determining a first object type indicated by the memory object allocation request; if no target Slab page exists, determining a Slab page that has released physical pages and is bound to the first object type as the first Slab page; wherein the target Slab page contains a free memory object of the first object type and has not released physical pages; after allocating the first physical page, establishing a mapping relationship between the first physical page and the first Slab page, and returning a free memory object initialized based on the first object type for the first physical page. Based on the memory object management method provided in this application embodiment, Slab pages are bound to object types. For any Slab page, even if the physical pages historically mapped to the Slab page are reclaimed, the type of memory objects in the Slab page remains unchanged after mapping to a new physical page. This avoids, to a certain extent, different types of memory objects sharing the virtual address represented by the same Slab page, effectively reducing the risk of cross-cache type obfuscation attacks.
[0082] In one embodiment, the memory object management provided in this application is applied to an allocator that manages memory objects, such as a Slab allocator, a Slub allocator, or a Slob allocator. The following embodiments will use an application to a Slub allocator as an example for illustration. See also... Figure 1 The memory object management method provided in this application includes the following steps:
[0083] S101: In response to a memory object allocation request, determine the first object type indicated by the memory object allocation request.
[0084] In this embodiment, when the kernel subsystem needs to create a memory object, it sends a memory object allocation request to the Slub allocator. The memory object allocation request can indicate the type of the required memory object (i.e., the first object type). For example, the type indicated by the memory object allocation request sent by the file system is a struct file object; the type indicated by the memory object allocation request sent by the device driver is a device_driver object.
[0085] S102: If the target Slab page does not exist, determine the Slab page that has been released from the physical page and bound to the first object type, and use it as the first Slab page.
[0086] The target Slab page contains a free memory object of type 1 object and the physical page has not been freed.
[0087] In this embodiment, when a memory object allocation request is received, the Slub allocator may have previously created other Slab pages, and each created Slab page is bound to a corresponding object type. For example, after creating a Slab page based on a memory object allocation request, the object type bound to that Slab page can be determined, and subsequently, the bound object type remains unchanged throughout the entire lifecycle of that Slab page. That is, regardless of whether the Slab page is currently mapped to a physical page, it is bound to that object type. A Slab page represents a fixed virtual address, that is, a range of virtual addresses. Accordingly, for multi-threaded and interrupt context scenarios, the object type binding of Slab pages is maintained, and attackers cannot induce type switching through page allocation, reducing the type confusion attack surface.
[0088] When a memory object allocation request is received, if the target Slab page does not currently exist (i.e., there is no Slab page (a released physical page bound to the first object type)), it means that a free memory object meeting the requirements cannot be directly obtained from an existing Slab page. In this case, the Slub allocator can determine if a Slab page with a released physical page bound to the first object type exists. If it does, the Slub allocator can create a free memory object based on these Slab pages in response to the memory object allocation request.
[0089] It is understandable that there may be one or more Slab pages that have been released from their physical pages and are bound to the first object type. If there is one, then that Slab page is determined as the first Slab page; if there are multiple, then one of these Slab pages can be selected as the first Slab page.
[0090] S103: After allocating the first physical page, establish the mapping relationship between the first physical page and the first Slab page, and return the free memory object obtained by initializing the first physical page based on the first object type.
[0091] In this embodiment, after determining the first Slab page, the Slub allocator can request the allocation of physical pages. For example, the Slub allocator requests the allocation of physical pages from the page allocator. The specific number of physical pages allocated can be determined based on the order maintained in the kmem_cache of the first object type.
[0092] After allocating a physical page (i.e., the first physical page), the kernel's Memory Management Subsystem (MMS) can establish a mapping relationship between the first physical page and the first slab page. Specifically, a PTE entry is generated, which records the mapping relationship between the physical address represented by the first physical page and the virtual address represented by the first slab page. Subsequently, the first physical page can be accessed through the virtual address represented by the first slab page based on this PTE entry.
[0093] Additionally, the Slub allocator can initialize the first physical page process based on the first object type. For example, it can divide the first physical page according to the size of the memory object of the first object type, resulting in multiple free memory objects. Then, it returns the virtual address of the first free memory object to the kernel subsystem in response to the memory object allocation request. The Slub allocator can also construct a free list corresponding to the remaining free memory objects to be allocated.
[0094] In other words, after mapping to a new physical page, the first Slab page still contains memory objects of the first object type. That is, when mapping to different physical pages, the type of memory objects in the first Slab page remains unchanged. In this way, different types of memory objects are prevented from sharing the virtual address represented by the same Slab page to a certain extent, effectively reducing the risk of cross-cache type confusion attacks.
[0095] In one embodiment, see Figure 2 Before step S102, the memory object management method includes: S104: Detecting whether a target Slab page exists in the object data virtual address area based on Slab entries in the metadata virtual address area; wherein, a Slab entry represents the object type bound to the corresponding Slab page in the object data virtual address area; step S102 includes: S1021: If the target Slab page does not exist in the object data virtual address area, determining the first Slab page from the Slab pages of released physical pages; wherein, the Slab entry corresponding to the first Slab page in the metadata virtual address area represents the first object type bound. Thus, a correspondence between Slab pages and Slab entries is constructed, and the object type bound to the corresponding Slab page is determined through the Slab entry. Furthermore, the metadata (i.e., Slab entries) of Slab pages can be quickly located without accessing physical page information, and the virtual address represented by the corresponding Slab page can be quickly determined through the Slab entry without traversing the cache or querying the page table, improving the efficiency of memory object management.
[0096] In one embodiment, a contiguous virtual address region is reserved in the high address space of the kernel, solely for slub allocation of memory objects. This virtual address region is divided into a data area (i.e., the object data virtual address area, used to store memory objects) and a metadata area (i.e., the metadata virtual address area, used to store the metadata of the slab page (i.e., struct slab)). It can be understood that the slab entries in this embodiment are the corresponding metadata of the slab page. The metadata includes: the object free list, the cache to which it belongs (kmem_cache), the number of objects, the order, and the head pointer of the composite slab page, etc. The cache to which it belongs represents the type of object bound to the corresponding slab page. The number of objects indicates the number of memory objects in the corresponding slab page; the order is used to determine the number of mapped physical pages; and the head pointer of the composite slab page indicates the address of the home page.
[0097] In other words, there is a one-to-one correspondence between the Slab pages in the object data virtual address space and the Slab entries in the metadata virtual address space. Thus, by reserving a segment of virtual address space specifically for the Slub allocator, the possibility of attackers directly logging into and attacking physical memory is effectively mitigated.
[0098] In one embodiment, the address of the data area is defined using new base address constants (such as VSLUB_BASE_ADDR and VSLUB_DATA_BASE_ADDR). VSLUB_BASE_ADDR defines the starting address of the reserved contiguous virtual address region; VSLUB_DATA_BASE_ADDR defines the starting address of the object data virtual address region. Correspondingly, the original folio_slab() path can be replaced by setting a virt_to_slab() interface, which allows for quick location of the corresponding metadata (i.e., Slab entries) based on the virtual address represented by the Slab page. Additionally, a slab_to_virt() interface is provided to implement reverse mapping, allowing the virtual address represented by the corresponding Slab page to be determined from the Slab entry without traversing all caches or page tables. In other words, a correspondence is established between the virtual address represented by the Slab page in the object data virtual address region and the virtual address of the corresponding Slab entry in the metadata virtual address region. This correspondence allows for quick addressing of Slab pages through Slab entries, and vice versa. This eliminates the need for addressing between physical pages / caches / page tables, further improving the efficiency of memory object management.
[0099] Since the Slab entry corresponding to a Slab page represents the type of object bound to that Slab page, the existence of a target Slab page can be determined based on the Slab entry in the metadata virtual address area. Similarly, the Slab page bound to the first object type and whose physical page has been released can also be determined based on the Slab entry in the metadata virtual address area. For example, the Slab entry can also record the status (i.e., whether it is free) of the memory objects in the corresponding Slab page. If all memory objects are free, it indicates that the Slab page has released its physical page.
[0100] In one embodiment, after responding to a memory object allocation request based on a free memory object in the first Slab page, the Slab entry corresponding to the first Slab page (referred to as the first Slab entry) can also be updated, such as updating the object free list recorded in the first Slab entry.
[0101] In one embodiment, the memory object management method further includes the following steps: if the target Slab page does not exist in the object data virtual address area, and the object data virtual address area does not have a released physical page bound to a first object type Slab page, a second Slab page is created in the object data virtual address area, and a Slab entry corresponding to the second Slab page is created in the metadata virtual address area; after allocating the second physical page, a mapping relationship between the second physical page and the second Slab page is established, a free memory object initialized based on the first object type is returned, and the Slab entry corresponding to the second Slab page is updated. In this way, a new Slab page can be created and bound to an object type to successfully respond to memory object allocation requests.
[0102] In this embodiment, if the Slab entry in the metadata virtual address area determines that neither a target Slab page nor a Slab page with a released physical page bound to a first object type exists, it indicates that the currently created Slab page cannot respond to memory object allocation requests. In this case, the Slub allocator creates a new Slab page (i.e., a second Slab page) and creates a corresponding Slab entry (which can be called a second Slab entry) in the metadata virtual address area. It is understood that the correspondence between the virtual address represented by the second Slab page and the virtual address of the Slab entry in the metadata virtual area can also be determined. Subsequently, addressing can be performed on both based on virt_to_slab() / slab_to_virt().
[0103] For example, the Slub allocator can determine the number of physical pages to be allocated and the virtual address represented by the second Slab page based on the first object type. Accordingly, the Slub allocator can create the second Slab page based on this information and request the allocation of physical pages. For example, it can select an unallocated virtual address from the object data virtual address area to obtain the virtual address represented by the second Slab page.
[0104] For details on establishing the mapping relationship between the second physical page and the second Slab page, please refer to the description of establishing the mapping relationship between the first physical page and the first Slab page in the previous embodiment. Similarly, the Slub allocator can initialize the free memory object obtained by initializing the second physical page based on the first object type. For details on initializing the second physical page based on the first object type, please refer to the description of initializing the first physical page based on the first object type in the previous embodiment.
[0105] For example, the `alloc_slab_page()` interface can be extended to include a `kmem_cache` context and dual GFP flags, enabling the `alloc_slab_page()` interface to implement the aforementioned process of responding to memory object allocation requests by creating a new second Slab page. One GFP flag is used for physical page allocation, and the other GFP flag is used to establish Slab entries and the mapping between Slab entries and Slab pages.
[0106] In addition, in the above embodiments, a fixed virtual address is allocated to the Slab page, and the allocated virtual address is aligned with the object memory, thereby improving memory access efficiency and reducing the overhead of address translation, and avoiding kernel errors caused by address misalignment.
[0107] Since the memory object allocation request is responded to based on the free memory objects in the second Slab page, the Slab entry corresponding to the second Slab page (i.e., the second Slab entry) can also be updated after responding to the memory object allocation request, such as updating the free list of objects recorded in the second Slab entry.
[0108] In one embodiment, the memory object management method further includes: when all memory objects in the first Slab page are in an idle state, deleting the mapping relationship between the first Slab page and the first physical page, releasing the first physical page asynchronously, and refreshing the page table buffer. This improves the security and efficiency of the memory reclamation mechanism.
[0109] In this embodiment of the application, if all memory objects in the first Slab page are in an idle state, in order to avoid invalid space occupation, the mapping relationship between the first Slab page and the first physical page can be deleted, the first physical page can be released, and the page table buffer can be refreshed.
[0110] For example, the Slub allocator can delete the PTE entry representing the mapping relationship between the first physical page and the first Slab page through the memory management subsystem, making it impossible to access the first physical page through the virtual address represented by the first Slab page.
[0111] In addition, page table buffer flushing and physical page reclamation are not suitable in scenarios such as interrupt contexts. Therefore, by asynchronously triggering the release of the first physical page and the flushing of the page table buffer, the safety and efficiency of the memory reclamation mechanism can be improved.
[0112] It is understood that, based on the memory object management method provided in this application embodiment, when all memory objects in the first Slab page are in an idle state, the corresponding physical page is released, but the corresponding Slab entry is still retained, so as to facilitate the subsequent mapping of a new physical page to the first Slab page, and to keep the object type bound to the first Slab page unchanged. In this way, by having metadata reside in the virtual address area, Freepointer verification and cache consistency checks remain effective even in scenarios where physical pages are missing.
[0113] In one embodiment, releasing the first physical page and refreshing the page table buffer asynchronously includes sending a release task to release the first physical page and a refresh task to refresh the page table buffer to the task queue corresponding to the kernel thread, so that the kernel thread refreshes the page table buffer and releases physical pages in batches according to the tasks in the task queue.
[0114] In this embodiment, the kernel thread can be the aforementioned Kthread thread. The task queue can be the aforementioned vslub_tlbflush_worker. If all memory objects in the first Slab page are in an idle state, the Slub allocator sends a release task to the task queue corresponding to the kernel thread to release the first physical page and a refresh task to refresh the page table buffer. Since page table buffer refresh is a global CPU instruction, based on the refresh tasks in the task queue, the kernel thread can merge multiple refreshes into one refresh, reducing the frequency of page table buffer refreshes and mitigating the impact on performance. Accordingly, the kernel thread performs batch release of multiple physical pages indicated by the received release tasks.
[0115] In one embodiment, after determining the first object type, the memory object management method further includes: if a target Slab page exists, decoding the pointers to free memory objects to be allocated in the free list of the target Slab page; performing alignment mask verification on the decoding result, and / or verifying whether the decoding result is within the virtual address represented by the target Slab page; if the verification result is not abnormal, returning the decoding result; if the verification result is abnormal, issuing an alarm. This enables secure pointer verification, preventing kernel Oops exceptions caused by corrupted free list pointers.
[0116] In this embodiment of the application, if a target Slab page exists, it indicates that the Slub allocator can directly obtain a free memory object from the target Slab page in response to the memory object allocation request.
[0117] Since each Slab page records a free memory object via a free list pointer, and this record contains the encoded virtual address, the Slub allocator decodes the pointers to the free memory objects to be allocated in the free list of the target Slab page, for example, using `freelist_ptr_decode()`, and then performs further verification. If the alignment mask verification is error-free, and the decoding result is within the virtual address represented by the target Slab page, it indicates that the decoding result is valid and the decoded virtual address can be used. The Slub allocator can then return the decoding result to the kernel subsystem. Conversely, if the Slub allocator determines that corruption exists, it can issue a warning. For example, the Slub allocator can perform alignment mask verification on the decoding result based on the size of the memory object of the first object type.
[0118] The Slub allocator determines whether a target Slab page meets the conditions for responding to a memory object allocation request by querying the corresponding Slab entry (which can be called the third Slab entry). Accordingly, the Slub allocator can also determine the virtual address represented by the target Slab page using the slab_to_virt() interface based on the third Slab entry.
[0119] In one embodiment, the memory object management method further includes: in response to a statistical query request for a second object type, returning the number of slab pages that have been released physical pages and bound to the second object type. This helps developers and operations personnel monitor memory release and virtual address occupancy.
[0120] In this embodiment, a new statistics interface, such as deallocated_pages, is added. When a statistics query request for an object type (i.e., the second object type) is received through the statistics interface, the number of slab pages that have been released and bound to the second object type can be determined and returned based on the Slab entries in the metadata virtual address area.
[0121] Based on the same inventive concept, embodiments of this application also provide a memory object management device, see [link to relevant documentation]. Figure 3 The device includes:
[0122] The first object type determination module 301 is used to determine the first object type indicated by the memory object allocation request in response to the memory object allocation request;
[0123] The first Slab page determination module 302 is used to determine, if no target Slab page exists, a Slab page that has released physical pages and is bound to the first object type as the first Slab page; wherein, the target Slab page contains a free memory object of the first object type and has not released physical pages;
[0124] The first response module 303 is used to establish a mapping relationship between the first physical page and the first Slab page after allocating the first physical page, and return a free memory object obtained by initializing the first physical page based on the first object type.
[0125] Optionally, the device further includes:
[0126] The detection module is used to determine whether a target Slab page exists in the object data virtual address area based on the Slab entries in the metadata virtual address area before determining that a released physical page and a Slab page bound to the first object type are used as the first Slab page if the target Slab page does not exist. Herein, a Slab entry represents the object type bound to the Slab page corresponding to the Slab page in the object data virtual address area.
[0127] The first Slab page determination module 302 is specifically used to determine the first Slab page from the Slab pages of the released physical pages if the target Slab page does not exist in the object data virtual address area; wherein, the Slab entry corresponding to the first Slab page in the metadata virtual address area represents the binding of the first object type.
[0128] Optionally, the device further includes:
[0129] The second response module is used to create a second Slab page in the object data virtual address area and create a Slab entry corresponding to the second Slab page in the metadata virtual address area if the target Slab page does not exist in the object data virtual address area and there is no Slab page that has been released and bound to the first object type.
[0130] After allocating the second physical page, a mapping relationship between the second physical page and the second Slab page is established. The free memory object obtained by initializing the second physical page based on the first object type is returned, and the Slab entry corresponding to the second Slab page is updated.
[0131] Optionally, the device further includes:
[0132] The release module is used to delete the mapping relationship between the first Slab page and the first physical page when all memory objects in the first Slab page are in an idle state, and to release the first physical page asynchronously, as well as refresh the page table buffer.
[0133] Optionally, the release module is specifically used to send a release task to release the first physical page and a refresh task to refresh the page table buffer to the task queue corresponding to the kernel thread, so that the kernel thread refreshes the page table buffer and releases physical pages in batches according to the tasks in the task queue.
[0134] Optionally, the device further includes:
[0135] The third response module is used to, in response to a memory object allocation request, determine the first object type indicated by the memory object allocation request, and if a target Slab page exists, decode the pointers to free memory objects to be allocated in the free list of the target Slab page.
[0136] Perform alignment mask verification on the decoding result, and / or verify whether the decoding result is within the virtual address represented by the target Slab page;
[0137] If the verification result is normal, return the decoding result; if the verification result is abnormal, issue an alarm.
[0138] Optionally, the device further includes:
[0139] The statistics query module is used to respond to a statistics query request for the second object type and return the number of Slab pages that have been released and bound to the second object type.
[0140] This application also provides an electronic device, such as... Figure 4As shown, it includes a processor 401, a communication interface 402, a memory 403, and a communication bus 404, wherein the processor 401, the communication interface 402, and the memory 403 communicate with each other through the communication bus 404.
[0141] Memory 403 is used to store computer programs;
[0142] When processor 401 executes the program stored in memory 403, it performs the following steps:
[0143] In response to a memory object allocation request, determine the first object type indicated by the memory object allocation request;
[0144] If the target Slab page does not exist, determine the Slab page that has released physical pages and is bound to the first object type, and use it as the first Slab page; wherein, the target Slab page contains a free memory object of the first object type and has not released physical pages;
[0145] After allocating the first physical page, a mapping relationship is established between the first physical page and the first Slab page, and a free memory object is returned based on the first object type to initialize the first physical page.
[0146] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.
[0147] The communication interface is used for communication between the aforementioned electronic devices and other devices.
[0148] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.
[0149] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.
[0150] In another embodiment provided in this application, a computer-readable storage medium is also provided, which stores a computer program that, when executed by a processor, implements the steps of any of the memory object management methods described above.
[0151] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute any of the memory object management methods described in the above embodiments.
[0152] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this 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. 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 wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. 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 integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)).
[0153] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
[0154] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, electronic devices, computer-readable storage media, and computer program products are basically similar to the method embodiments, and therefore the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.
[0155] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application are included within the scope of protection of this application.
Claims
1. A memory object management method, characterized in that, The method includes: In response to a memory object allocation request, determine the first object type indicated by the memory object allocation request; If the target Slab page does not exist, determine the Slab page that has released physical pages and is bound to the first object type, and use it as the first Slab page; wherein, the target Slab page contains a free memory object of the first object type and has not released physical pages; After allocating the first physical page, establish a mapping relationship between the first physical page and the first Slab page, and return the free memory object obtained by initializing the first physical page based on the first object type; The method further includes: When all memory objects in the first Slab page are in an idle state, the mapping relationship between the first Slab page and the first physical page is deleted, the first physical page is released asynchronously, and the address translation cache is refreshed.
2. The method according to claim 1, characterized in that, Before determining that a physical page has been released and a Slab page bound to the first object type is used as the first Slab page if the target Slab page does not exist, the method further includes: Based on the Slab entries in the metadata virtual address area, detect whether the target Slab page exists in the object data virtual address area; where a Slab entry represents the object type bound to the corresponding Slab page in the object data virtual address area; If the target Slab page does not exist, determining the Slab page that has been released from the physical page and bound to the first object type as the first Slab page includes: If the target Slab page does not exist in the object data virtual address area, the first Slab page is determined from the Slab pages of the released physical pages; wherein, the Slab entry corresponding to the first Slab page in the metadata virtual address area represents the binding of the first object type.
3. The method according to claim 2, characterized in that, The method further includes: If the target Slab page does not exist in the object data virtual address area, and there is no Slab page that has been released and bound to the first object type, a second Slab page is created in the object data virtual address area, and a Slab entry corresponding to the second Slab page is created in the metadata virtual address area. After allocating the second physical page, a mapping relationship between the second physical page and the second Slab page is established. The free memory object obtained by initializing the second physical page based on the first object type is returned, and the Slab entry corresponding to the second Slab page is updated.
4. The method according to claim 1, characterized in that, The asynchronous release of the first physical page and the flushing of the page table buffer include: A release task to release the first physical page and a refresh task to refresh the page table buffer are sent to the task queue corresponding to the kernel thread, so that the kernel thread refreshes the page table buffer and releases physical pages in batches according to the tasks in the task queue.
5. The method according to any one of claims 1-3, characterized in that, After determining the first object type indicated by the memory object allocation request in response to the memory object allocation request, the method further includes: If a target Slab page exists, decode the pointers to the free memory objects to be allocated in the free list of the target Slab page; Perform alignment mask verification on the decoding result, and / or verify whether the decoding result is within the virtual address represented by the target Slab page; If the verification result is normal, return the decoding result; if the verification result is abnormal, issue an alarm.
6. The method according to any one of claims 1-3, characterized in that, The method further includes: In response to a statistics query request for the second object type, return the number of Slab pages that have been released and bound to the second object type.
7. A memory object management device, characterized in that, The device includes: The first object type determination module is used to determine the first object type indicated by the memory object allocation request in response to the memory object allocation request; The first Slab page determination module is used to determine, if the target Slab page does not exist, a Slab page that has released physical pages and is bound to the first object type as the first Slab page; wherein, the target Slab page contains a free memory object of the first object type and has not released physical pages; The first response module is used to establish a mapping relationship between the first physical page and the first Slab page after allocating the first physical page, and return a free memory object obtained by initializing the first physical page based on the first object type. The device further includes: The release module is used to delete the mapping relationship between the first Slab page and the first physical page when all memory objects in the first Slab page are in an idle state, and to release the first physical page asynchronously, as well as refresh the page table buffer.
8. The apparatus according to claim 7, characterized in that, The device further includes: The detection module is used to determine whether a target Slab page exists in the object data virtual address area based on the Slab entries in the metadata virtual address area before determining that a released physical page and a Slab page bound to the first object type are used as the first Slab page if the target Slab page does not exist. Herein, a Slab entry represents the object type bound to the Slab page corresponding to the Slab page in the object data virtual address area. The first Slab page determination module is specifically used to determine the first Slab page from the Slab pages of the released physical pages if the target Slab page does not exist in the object data virtual address area; wherein, the Slab entry corresponding to the first Slab page in the metadata virtual address area represents the binding of the first object type.
9. The apparatus according to claim 8, characterized in that, The device further includes: The second response module is used to create a second Slab page in the object data virtual address area and create a Slab entry corresponding to the second Slab page in the metadata virtual address area if the target Slab page does not exist in the object data virtual address area and there is no Slab page that has been released and bound to the first object type. After allocating the second physical page, a mapping relationship between the second physical page and the second Slab page is established. The free memory object obtained by initializing the second physical page based on the first object type is returned, and the Slab entry corresponding to the second Slab page is updated.
10. The apparatus according to claim 7, characterized in that, The release module is specifically used to send a release task to release the first physical page and a refresh task to refresh the page table buffer to the task queue corresponding to the kernel thread, so that the kernel thread refreshes the page table buffer and releases physical pages in batches according to the tasks in the task queue.
11. The apparatus according to any one of claims 7-9, characterized in that, The device further includes: The third response module is used to, in response to a memory object allocation request, determine the first object type indicated by the memory object allocation request, and if a target Slab page exists, decode the pointers to free memory objects to be allocated in the free list of the target Slab page. Perform alignment mask verification on the decoding result, and / or verify whether the decoding result is within the virtual address represented by the target Slab page; If the verification result is normal, return the decoding result; if the verification result is abnormal, issue an alarm.
12. The apparatus according to any one of claims 7-9, characterized in that, The device further includes: The statistics query module is used to respond to a statistics query request for the second object type and return the number of Slab pages that have been released and bound to the second object type.
13. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the steps of the method described in any one of claims 1-6.
14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method described in any one of claims 1-6.