Lightweight operating system memory management subsystem based on rust language

Abstract

The application discloses a lightweight operating system memory management subsystem based on Rust language, which comprises a processor architecture abstraction layer, an allocator and mapper layer and a user space management layer, the allocator and mapper layer comprises a kernel allocator, a kernel page mapper and an MMIO space management mechanism; the processor architecture abstraction layer is used for providing a unified abstraction for shielding hardware details for the allocator and mapper layer; the kernel allocator is used for managing allocation and recovery of memory space, and is connected to the user space management layer and the MMIO space management mechanism upward, and is connected to the architecture abstraction layer downward; the kernel page mapper is used for mapping the memory space to a processor page table, and is connected to the user space management layer and the MMIO space management mechanism upward, and is connected to the architecture abstraction layer downward, and is connected to the kernel allocator laterally; and the user space management layer comprises a posix standard system call interface. The subsystem provided by the application has the characteristics of lightweight, high safety, good compatibility and scalability.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of operating system kernel, and particularly relates to a lightweight operating system memory management subsystem based on a Rust language. BACKGROUND

[0002] The memory management subsystem is one of important components of the operating system kernel, and in the field of embedded devices, memory management is crucial to the safety and performance of the operating system. However, the traditional memory management method may have security vulnerabilities and performance bottlenecks, and the memory management subsystem itself also needs to occupy a part of memory resources, while the memory resources on the embedded device are relatively limited. Therefore, a safe, high-performance and lightweight memory management subsystem is needed.

[0003] At present, in the field of embedded devices, the memory management subsystems of mainstream operating systems such as Linux, RT-Thread and openHarmony are developed using C language. Due to the lack of formal verification mechanism and compile-time memory protection mechanism in C language, a lot of work is needed to verify the safety and correctness of the memory management subsystem.

[0004] The Rust language provides a powerful type system, lifetime mechanism and Affine Logic theory, which divides the code into Safe and Unsafe two areas. Software developers can use the language features provided by Rust to design objects that provide security to improve software robustness and security. SUMMARY

[0005] In view of the problem that the existing lightweight memory management subsystem lacks compile-time security mechanism, the application provides a lightweight operating system memory management subsystem based on Rust language.

[0006] The purpose of the application is to provide a lightweight operating system memory management subsystem based on Rust language, which can achieve the following technical solutions:

[0007] A lightweight operating system memory management subsystem based on Rust language, comprising a processor architecture abstraction layer, an allocator and mapper layer and a user space management layer, the allocator and mapper layer comprising a kernel allocator, a kernel page mapper and an MMIO space management mechanism, wherein:

[0008] The processor architecture abstraction layer is used for abstraction of hardware memory management features of CPUs of all instruction architectures, and provides a unified abstraction shielding hardware details for the allocator and mapper layer;

[0009] The kernel allocator is configured to manage the allocation and recycling of memory space, and as an intermediate layer, it is connected to the user space management layer and the MMIO space management mechanism above, and to the architecture abstraction layer below.

[0010] The kernel page mapper is configured to map memory space to processor page tables, and as an intermediate layer, it is connected to the user space management layer and the MMIO space management mechanism above, and to the architecture abstraction layer below, and it is also connected to the kernel allocator laterally.

[0011] The MMIO space management mechanism is configured to effectively manage the virtual address space required by MMIO and the physical address mapping of MMIO.

[0012] The user space management layer is configured to allocate virtual memory regions to user processes, including the posix standard system call interface, as well as components for page mapping and VMA management.

[0013] Further, each mapper instance in the kernel page mapper holds a page table base address, and when mapping a physical address to a virtual space, the following steps are performed:

[0014] Security check: check if the physical and virtual addresses are legal, and if the permissions and attributes to be mapped are legal;

[0015] Fill in the page table: find the page table layer by layer, and create it if it does not exist; in this process, the architecture abstraction layer functions are called to create, find, and fill in the page table; during the filling process, legality checks are performed, and if illegal, an error is immediately thrown;

[0016] TLB flush: detect the processor where the address space is located, and then decide whether to flush the TLB and how to flush the TLB, and then create a TLB flusher; if the address space is already effective in the current processor, directly flush the page table entry; if the address space is effective in another processor, a cross-processor flush inter-core communication call will be generated, and the flusher is passed to the target processor, so that the target core enters the flush processing program and executes the page table entry flush.

[0017] Further, the kernel page mapper uses a local core reentrant spin lock mechanism, which allows the current core to obtain read-only permissions of the allocator while a core has obtained write permissions of the allocator, making the operation of detecting page table entry mapping more convenient.

[0018] Further, the working process of the local core reentrant spin lock mechanism is as follows:

[0019] Locking process:

[0020] Determine whether the current core holds the lock.

[0021] If not, return the guard object with read-write permission, and increment the guard count, and end the process;

[0022] Otherwise, continue to determine whether it is the current core, if yes, return the guard object with read-only permission, and increment the guard count, and end the process; otherwise, it indicates that this attempt to lock fails, return to determine whether there is a core holding the lock at present;

[0023] The guard object is a credential for program to access data, and if there is no guard object, the protected data cannot be accessed;

[0024] The release process is as follows:

[0025] Reduce the guard count;

[0026] If the guard count is zero, release the lock and end the process; otherwise, directly end the process.

[0027] Further, the kernel page mapper also adopts an address type safety check mechanism; based on the check and conversion functions of the Rust type system, the physical address and the virtual address are respectively encapsulated into different objects, and in the From and Into two characteristic methods of the conversion, the linear offset data and the memory relocation data provided by the architecture abstraction layer are introduced to realize the conversion between the physical address and the virtual address.

[0028] Further, the page allocator adopts the buddy algorithm, and combines the Rust lifetime mechanism to design safety-related objects, so as to reduce the security risks of the kernel allocator.

[0029] Further, the kernel allocator adopts a linked list page to manage the memory block; the linked list page is a data structure for storing the information of the memory block and is linked together in a certain order; in the linked list page, the first element points to the pointer of the next memory block to form a linked list; the second element of each linked list page indicates how many available blocks are contained in the current linked list page; in the buddy system memory allocator using the linked list page, the memory blocks are organized into different groups, and each group corresponds to multiple linked list pages.

[0030] Further, the MMIO space management mechanism adopts a static memory access verification technology to improve the safety of the driver when accessing the memory;

[0031] When the MMIO virtual address space is allocated, the MMIO layer creates an MMIO Guard guard object, and the subsequent physical memory mapping is also bound to the guard object; once the lifetime of the guard object ends and is released, the MMIO layer automatically releases the virtual address space and the physical page mapped in the page table.

[0032] Further, at the compilation period, the memory access operation is bound with the type system and the life mechanism of Rust through the life mechanism of Rust, and the creation, mapping, access and release of the MMIO virtual address space are tracked, so that the code that violates the memory access rule also violates the type system and the life rule of Rust, so that the problematic code cannot pass the compilation, thereby achieving the purpose of static safety check.

[0033] Further, the posix standard system call interface layer complies with the posix2008 specification.

[0034] The present application has the following beneficial effects relative to the prior art:

[0035] 1. The subsystem provided by the present application has high safety: the type system and the life mechanism of Rust are used in the MMIO space management mechanism, based on the Affine Logic theory, to realize the static safety check at the compilation period, avoiding the safety problems caused by coding errors. Meanwhile, the address type safety check mechanism is used in the page mapper to avoid the error of mixing physical addresses and virtual addresses. In addition, the memory protection mechanism is used, and through the permission control mechanism based on the guard object, the UAF safety problem and the memory out-of-bound problem can be checked during the compilation to a certain extent;

[0036] 2. The subsystem provided by the present application has high performance: the buddy algorithm and the life mechanism of Rust are used in the page allocator, reducing the possible safety hazards of the memory allocator and improving the performance of memory management. Meanwhile, the local core reentrant spin lock mechanism is used in the kernel page mapper to improve the real-time performance of the interrupt and reduce the code complexity. In addition, the efficient memory allocation algorithm is used in the page allocator to further improve the performance of memory management;

[0037] 3. The subsystem provided by the present application is lightweight: the module composition of the whole subsystem is relatively simple, and the computing resources and space resources are less occupied, which is suitable for use on devices with limited resources;

[0038] 4. The subsystem provided by the present application has good compatibility: the posix2008 specification is followed, the posix standard system call interface layer is provided, and the existing operating system and application program are compatible. In addition, the modular design is adopted, so that the memory management subsystem can be conveniently integrated with other system components;

[0039] 5、The subsystem provided by the application has high expansibility: the application divides the memory management subsystem into three layers, so that the system structure is clear, easy to maintain and upgrade. In addition, modular design is adopted, so that each component of the memory management subsystem can be developed and maintained independently. Through the MMIO management mechanism, the virtual address space and physical address mapping required by MMIO can be conveniently managed, a safe and stable way of accessing memory is provided for the driver, the memory access safety of the driver is improved, and a public interface is provided for the driver memory access. BRIEF DESCRIPTION OF DRAWINGS

[0040] In order to more clearly illustrate the technical solutions in the embodiments of the application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or the prior art description. Obviously, the drawings in the following description are only some embodiments of the application, and for those skilled in the art, other drawings can also be obtained from the structures shown in these drawings without creative labor.

[0041] Figure 1 Structure diagram of the memory management subsystem of the lightweight operating system based on Rust language in embodiment 1 of the application;

[0042] Figure 2 Flowchart of acquiring lock in the local core reentrant spin lock in embodiment 1 of the application;

[0043] Figure 3 Flowchart of releasing guard in the local core reentrant spin lock in embodiment 1 of the application;

[0044] Figure 4 An implementation manner of the lightweight linked list page buddy system in embodiment 1 of the application;

[0045] Figure 5 Flowchart of mapping MMIO space in the MMIO space management mechanism in embodiment 1 of the application;

[0046] Figure 6 Flowchart of releasing MMIO guard in the MMIO space management mechanism in embodiment 1 of the application;

[0047] Figure 7 Splitting diagram of VMA in embodiment 1 of the application;

[0048] Figure 8 Flowchart of user memory allocation in embodiment 1 of the application. DETAILED DESCRIPTION

[0049] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention. It should be understood that the specific embodiments described are merely used to explain this application and are not intended to limit this application.

[0050] Example:

[0051] like Figure 1 As shown, the lightweight operating system memory management subsystem based on the Rust language provided in this embodiment includes three layers: a processor architecture abstraction layer, an allocator and mapper layer, and a user space management layer. The allocator and mapper layer includes three modules: a kernel allocator, a kernel page mapper, and an MMIO space management mechanism. This memory management subsystem is lightweight and has a static security check mechanism.

[0052] (1) Architecture abstraction layer.

[0053] The architecture abstraction layer (AIL) abstracts the hardware memory management characteristics of CPUs across all instruction set architectures. It provides a unified abstraction that hides hardware details from the allocator and mapper layers. For different processor architectures, such as x86-64, ARM64, and RISC-V64, specific processor-specific features, such as page mapping, permission settings, and TLB refresh, are implemented within the AIL.

[0054] In its implementation, the architecture abstraction layer includes the definition of architecture-related constants and function interfaces.

[0055] The architecture-related constants are defined as follows:

[0056] Page table parameters (PAGE_SHIFT, PAGE_ENTRY_SHIFT, PAGE_LEVELS, ENTRY_ADDRESS_SHIFT) and page table entry flags (ENTRY_FLAG_xxx) are used to define specific attributes or functions of the page table.

[0057] The virtual address parameters (PHYS_OFFSET, PAGE_SIZE, PAGE_MASK, PAGE_ADDRESS_SHIFT, PAGE_ADDRESS_MASK) are used to indicate page offset, page size, page mask, etc. These fields can be automatically generated by the architecture abstraction layer based on the constants in the "page table parameters" section, or specific values ​​can be directly specified by the specific architecture.

[0058] Other parameters (USER_END_VADDR, USER_BRK_START, USER_STACK_START), which are constants related to user process address space management, mark the start and end addresses of the user stack.

[0059] Architecture-dependent function interfaces include the following:

[0060] Initialize the memory management module: This interface is used to initialize the architecture abstraction layer and create the corresponding page table;

[0061] Read virtual address: This interface is used to read the content of the specified virtual address;

[0062] Write virtual address: This interface is used to write data to the specified virtual address;

[0063] Flush TLB entry: This interface is used to flush the TLB entry corresponding to the virtual address, ensuring that the new virtual address mapping is correctly updated;

[0064] Set page table: This interface is used to set or update the top-level page table entry of the page table, thereby changing the mapping of virtual address to physical address;

[0065] Judge virtual address validity: This interface is used to judge whether a virtual address is valid. For example, whether it is within the range of kernel space or whether it has been mapped to physical memory.

[0066] Create a new user mapper: This interface is used to create a new user mapper to create and update the page table for user processes.

[0067] (2) Allocator and mapper layer.

[0068] The allocator and mapper layer includes the kernel allocator unified interface, kernel page allocator, page mapper, and MMIO space management mechanism.

[0069] (2-1) Dynamic memory allocation request flow.

[0070] The kernel's dynamic memory allocation request goes through the following path to obtain:

[0071] The allocation request enters from the kernel allocator unified interface;

[0072] According to the space size and alignment requirements of the allocation request, it is distributed to the page allocator or the appropriate cache pool;

[0073] Allocate space and return the start address of the space.

[0074] (2-2) Kernel page mapper.

[0075] The page mapper is a mechanism for mapping memory space to the processor's page table, as an intermediate layer, it interfaces with the user space management layer and MMIO space management mechanism upwards, and directly interfaces with the architecture abstraction layer downwards, while horizontally interfaces with the kernel allocator.

[0076] The implementation principle of the page mapper: each mapper instance holds a page table base address, when mapping a physical address to a virtual space, the following steps are performed:

[0077] Security check: check whether the physical and virtual addresses are legal, and whether the permissions and attributes to be mapped are legal;

[0078] Fill in the page table: find the page table layer by layer, and create it if it does not exist. This part will call the functions of the architecture abstraction layer to create, find and fill in the page table. During the filling process, legality check will be performed, and if it is not legal, an error will be thrown immediately;

[0079] TLB flush: detect the processor where the address space is located, so as to decide whether to flush the TLB and how to flush the TLB, and then create a TLB flusher. If the address space is already in effect in the current processor, the page table entry is directly flushed. If the address space is in effect in another processor, a cross-processor flush inter-core communication call will be generated, and the flusher is passed to the target processor, so that the target core enters the flush processing program to execute the page table entry flush.

[0080] Since the call path involves a wide range of aspects and the number of calls is frequent, it is very important to improve the performance of the page mapper. In order to ensure the mutual exclusion access of the allocator while improving the real-time performance of the interrupt and reducing the code complexity, the kernel page mapper provides a "processor core local reentrant spin lock" mechanism, which allows the current core to obtain the "read-only permission" of the allocator again under the condition that a certain core has obtained the "write permission" of the allocator spin lock. This mechanism makes the detection of page table entry mapping more convenient and faster.

[0081] As shown in Figure 2 , 3 , the working mechanism of the local core reentrant spin lock is as follows:

[0082] Locking process:

[0083] Determine whether the current core holds the lock, if not, return the guard object with read and write permissions, and increment the guard count; otherwise, continue to determine whether it is the current core, if so, return the guard object with read-only permission; otherwise, it indicates that the current attempt to lock fails, and return to determine whether the current core holds the lock;

[0084] The guard object is a "credential" for the program to access data, and if there is no guard object, the protected data cannot be accessed.

[0085] The release process is as follows:

[0086] Reduce the guard count;

[0087] If the guard count is zero, release the lock; otherwise, end.

[0088] In this embodiment, the page mapper also adopts an address type safety check mechanism. Based on the check and conversion functions of the Rust type system, the mechanism encapsulates the "physical address" and "virtual address" into different objects respectively, and in the From and Into two feature methods of the conversion, introduces the linear offset data and memory relocation data provided by the architecture abstraction layer to realize the conversion of the physical address and the virtual address. This check mechanism can avoid the error of mixing physical address and virtual address due to coding error at the compilation period.

[0089] (2-3) Kernel allocator.

[0090] The implementation of the light-weight linked list page buddy system memory allocator is shown in Figure 4 Each memory block in the buddy system is managed using a structure called "linked list page". Through experimental testing, on a machine with E5-2696v3 processor and DDR3 1133Mhz, the allocation speed of this linked list page allocator is 91.4GB / s when using random size allocation.

[0091] There are 19 sizes of memory blocks, ranging from 4K to 1G. The linked list page is a data structure that stores information about memory blocks and is linked together in a certain order. The size of each linked list page is 4K, and the size of each entry is 8 bytes, with a total of 512 entries. In the linked list page, the first element is a pointer to the next memory block, forming a linked list. The second element of each linked list page indicates how many available blocks are contained in the current linked list page. In the buddy system memory allocator using linked list pages, memory blocks are organized into different groups, and each group corresponds to multiple linked list pages.

[0092] When memory needs to be allocated, the system will request free memory blocks from the first linked list page in the corresponding group according to the requested size. If there are not enough free memory blocks in this group for allocation, the system will check other groups for sufficient available memory blocks. The strategy of splitting first and merging later is used to increase the number of available blocks in the current memory group. If the above operations still cannot make the current linked list group have enough memory pages, an OOM error is thrown.

[0093] When reclaiming memory, the kernel allocator looks for its buddy in the current memory group, and if it has one, it merges the buddy and inserts it into the higher level memory group. If the first list page of the memory group is full at this time, it will be handled differently: if the current group is 4K in size, the memory block to be returned will be directly added to the list as a list page, otherwise the "allocation" process will be executed to expand the current list.

[0094] (2-4) MMIO space management mechanism.

[0095] The MMIO management mechanism mainly includes the strategy for effectively managing the virtual address space required for MMIO and the physical address mapping of MMIO.

[0096] The innovation of the MMIO management mechanism in the embodiment is to introduce a static memory access verification technology to improve the safety of the driver when accessing memory.

[0097] As shown in Figure 5 , 6 In one embodiment, when the MMIO virtual address space is allocated, the MMIO layer creates an MMIO Guard guard object, and the subsequent physical memory mapping is also bound to the guard object. Once the life cycle of the guard ends and is released, the MMIO layer will automatically release the virtual address space and the physical page mapped in the page table.

[0098] At the compilation stage, the memory access operation is bound to the Rust type system and life cycle mechanism through the Rust life cycle mechanism, and the creation, mapping, access, and release of the MMIO virtual address space are tracked. The code that violates the memory access rules also violates the Rust type system and life cycle rules, so that the problematic code cannot pass the compilation, achieving the purpose of static safety check. This way improves the safety of the driver when accessing memory, effectively preventing security issues such as illegal access and data leakage, and further improving the security and stability of the operating system.

[0099] (3) User space management layer.

[0100] The user space management layer includes the posix standard system call interface, as well as the page mapping and VMA management components. The posix standard system call interface layer complies with the posix2008 specification.

[0101] (3-1) Concept of VMA.

[0102] VMA is short for Virtual Memory Area. It represents a section of address space in a user process address space, which should have the same page permissions and page attributes.

[0103] Page permissions refer to the memory access permissions of this section of address space, which are divided into read, write, and executable permissions. These permissions are issued by the page mapping mechanism to the page table, making them effective.

[0104] Page attributes refer to the page type of this section of memory space. According to whether it corresponds to real memory, it is divided into "anonymous page" and "backing page".

[0105] According to whether the VMA is shared among multiple user processes, it is divided into "private page" and "shared page". When the kernel loads a process, or the user process calls the kernel through the posix interface, the modification of the memory space will be reflected as the modification of the VMA permissions, creation, destruction, merging, etc.

[0106] (3-2) VMA life cycle.

[0107] The life cycle of VMA includes creation, merging, splitting, and destruction.

[0108] Creation: When a new process is created, its address space will contain a series of VMAs to divide different memory regions, such as code segment, data segment, heap, and stack, etc. At the same time, when the user program calls "mmap" or "sbrk" system calls, new VMAs will be created.

[0109] Splitting: When the user process performs unmap operation, if the user-unmapped memory range is within the VMA, it will cause the VMA to split. As shown in Figure 7 , after splitting the initial VMA, two new VMAs (VMA1 and VMA2) with the same attributes and permissions are generated, and a memory hole is also generated.

[0110] Merging: If two VMAs on the same address space are closely connected and have the same permissions, they can be merged into one VMA. The address space occupied by the merged VMA is the space occupied by the original two VMAs.

[0111] Destruction: When a VMA is converted into a memory hole, it will be destroyed.

[0112] (3-3) User memory allocation process.

[0113] As shown in Figure 8 , when the user process applies for memory to the kernel, the following steps will be performed:

[0114] System call mmap(), enter kernel, try to create VMA;

[0115] If the user passed in memory space is empty hole, then create VMA, otherwise end;

[0116] After the VMA is created, memory pages are applied to the memory allocator. If the allocation fails, then destroy the VMA and end;

[0117] Map memory pages to the page table, and then the flow ends.

[0118] Those skilled in the art can understand that all or part of the steps in the method for implementing the above embodiments can be instructed by a program to relevant hardware, and the corresponding program can be stored in a computer readable storage medium.

[0119] It should be noted that although the algorithm operations in the embodiments are described in a specific order in the accompanying drawings, this does not require or imply that the operations must be performed in this specific order, or that all of the shown operations must be performed to achieve the desired results. On the contrary, the steps depicted can change the order of execution. Additionally or alternatively, certain steps can be omitted, multiple steps can be combined into one step execution, and / or one step can be divided into multiple steps.

[0120] The above is only the preferred embodiment of the present application, but the protection scope of the present application is not limited to this. Any skilled person in the art can make equivalent replacement or change according to the technical scheme and the inventive concept of the present application within the scope disclosed by the present application, and it still belongs to the protection scope of the present application.

Claims

1. A lightweight operating system memory management subsystem based on Rust language, characterized in that, The processor architecture abstraction layer, the allocator and mapper layer including a kernel allocator, a kernel page mapper and an MMIO space management mechanism, and a user space management layer, wherein: The processor architecture abstraction layer is configured to abstract hardware memory management features of CPUs of all instruction architectures, and provide a unified abstraction shielding hardware details for the allocator and mapper layer; The kernel allocator is configured to manage allocation and recycling of memory space, and as an intermediate layer, is connected to the user space management layer and the MMIO space management mechanism upward, and connected to the processor architecture abstraction layer downward; The kernel page mapper is configured to map memory space to a processor page table, and as an intermediate layer, is connected to the user space management layer and the MMIO space management mechanism upward, connected to the processor architecture abstraction layer downward, and connected to the kernel allocator laterally, wherein the kernel page mapper adopts an address type safety check mechanism; the mechanism is based on the check and conversion functions of the type system of Rust, and realizes conversion of physical addresses and virtual addresses by encapsulating the physical addresses and the virtual addresses into different objects respectively, and introducing linear offset data and memory relocation data provided by the processor architecture abstraction layer into From and Into two characteristic methods of conversion; The MMIO space management mechanism is configured to effectively manage virtual address space required by MMIO and physical address mapping of MMIO; The user space management layer is configured to allocate virtual memory regions for user processes, and includes a posix standard system call interface, and components of page mapping and VMA management; In the compilation period, the memory access operation is bound to the type system and the life cycle mechanism of Rust through the life cycle mechanism of Rust, and creation, mapping, access and release of MMIO virtual address space are tracked.

2. The lightweight operating system memory management subsystem of claim 1, wherein, In the kernel page mapper, each mapper instance holds a page table base address, and when a physical address is mapped to a virtual space, the following steps are performed: Safety check: check whether the physical and virtual addresses are legal, and whether the permissions and attributes to be mapped are legal; Fill in the page table: find the page table layer by layer, and create the page table if the page table does not exist; In this process, the functions of the processor architecture abstraction layer are called to realize creation, finding and filling of the page table; during the filling process, legality check is performed, and if the legality is not met, an error is thrown immediately; TLB flushing: detect the processor where the address space is located, so as to determine whether to flush the TLB and how to flush the TLB, and then create a TLB flusher; If the address space is already effective in the current processor, the page table entry is directly flushed; if the address space is effective in another processor, a cross-processor flushing inter-core communication call is generated, and the flusher is passed to the target processor, so that the target core falls into a flushing processing program to execute page table entry flushing.

3. The lightweight operating system memory management subsystem of any of claims 1-2, wherein, The kernel page mapper adopts a local core reentrant spin lock mechanism, which allows the current core to acquire read-only permission of the kernel allocator again in the case that a certain core has acquired write permission of the kernel allocator.

4. The lightweight operating system memory management subsystem of claim 3, wherein, The working process of the local core reentrant spinlock mechanism is as follows: The locking process is as follows: Determine whether the current core holds the lock; If not, return the guard object with read-write permission, and increment the guard count, and end the process; Otherwise, continue to determine whether it is the current core, if yes, return the guard object with read-only permission, and increment the guard count, and end the process; otherwise, it indicates that the current attempt to lock fails, and return to determine whether the current core holds the lock; The guard object is a credential for program access to data, and if there is no guard object, the protected data cannot be accessed; The release process is as follows: Reduce the guard count; If the guard count is zero, release the lock and end the process; otherwise, directly end the process.

5. The lightweight operating system memory management subsystem of any of claims 1-2, wherein, The kernel allocator adopts the buddy algorithm and the Rust lifetime mechanism.

6. The lightweight operating system memory management subsystem of any of claims 1-2, wherein, The kernel allocator adopts a linked list page to manage memory blocks; The linked list page is a data structure for storing information of memory blocks and is linked together in a certain order; in the linked list page, the first element points to the pointer of the next memory block, forming a linked list; the second element of each linked list page indicates how many available blocks are contained in the current linked list page; in the buddy system kernel allocator using the linked list page, the memory blocks are organized into different groups, and each group corresponds to multiple linked list pages.

7. The lightweight operating system memory management subsystem of any of claims 1-2, wherein, The MMIO space management mechanism adopts a static memory access verification technology to improve the safety of the driver when accessing memory; When the MMIO virtual address space is allocated, the MMIO layer creates an MMIO Guard guard object, and the subsequent physical memory mapping is also bound to the guard object; once the lifetime of the guard object ends and is released, the MMIO layer automatically releases the virtual address space and the physical page mapped in the page table.

8. The lightweight operating system memory management subsystem of any of claims 1-2, wherein, The posix standard system call interface layer complies with the posix2008 specification.

Images