Shared memory system and implementation method

Abstract

The invention provides a shared memory system and an implementation method, and the system comprises an SVMA module which is used for distributing a shared virtual address interval SVMA of a shared memory for each process participating in communication; the shared virtual address interval SVMA comprises a plurality of sharing slots, the n sharing slots are screened on the basis of the plurality of sharing slots to serve as n Consections, and the n Consections are randomly distributed in the shared virtual address interval SVMA; the processes with the same IPC requirement share the same Consection; the connection comprises a plurality of shared sub-slots (Sharing Subslots), and the number of the shared sub-slots (Sharing Subslots) is larger than the number of the shared sub-slots (Sharing The memory manager module is used for carrying out fine-grained management on the Sharing Subslot by utilizing a user mode memory manager; wherein the user mode memory manager is a multi-level linked list type memory manager, and a shared sub slot is divided into a plurality of memory pools with different sizes by utilizing the multi-level linked list type memory manager, and the memory pools are organized by using linked lists.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of shared memory, in particular to a shared memory system and an implementation method, and more particularly to a shared memory system and an implementation method for realizing high-performance fine-grained strong isolation. BACKGROUND

[0002] In a computer system, inter-process communication is crucial, and shared memory, as an efficient inter-process communication mechanism, is widely used in many scenarios. It allows multiple processes to share a block of physical memory, avoiding the overhead of copying data between different processes, and plays a key role in scenarios that require high performance and low latency. However, the traditional shared memory mechanism has many problems. On the one hand, its creation requires the assistance of the operating system kernel, and the process needs to be plunged into the kernel through a system call, and the kernel then modifies the page table to establish a mapping. This process, whether it is the plunge of the user state or the modification of the page table and other data structures in the kernel, consumes additional CPU cycles. In certain scenarios, if the memory sharing interface is called frequently and the allocation operation is in the application critical path, the performance overhead cannot be ignored. On the other hand, the isolation of shared memory is insufficient. Although globally pre-allocated shared memory avoids the overhead of plunging and modifying the page table by establishing a shared region in advance and mapping it to all process address spaces, all processes can directly access this region, which poses a risk of malicious processes reading information and process code bugs mistakenly writing to other process shared memory regions. In addition, existing memory management has problems of coarse granularity and static nature, making it difficult to meet the needs of flexible creation of shared memory by different processes and support for different granularity memory sizes. At the same time, other inter-process communication methods such as message queues, sockets, and pipes, while having certain advantages in isolation, do not perform as well as shared memory in terms of performance. Address Space Layout Randomization (ASLR), as an important security technology, can enhance system security, but it does not effectively solve the key problems of shared memory performance and isolation. Therefore, it is urgent to develop a shared memory mechanism that balances high performance, fine-grained memory management, and strong isolation.

[0003] Patent document CN117112268A (application number: 202311375032.5) discloses a memory sharing management method and system, including a virtual twin module, a data mapping module, a write processing module, and a mapping filing module. Through the setting of related functional modules, memory sharing management based on virtual memory space is realized, and high-heat data in each process or between multiple processes is written to shared memory, thereby facilitating the access of multiple tasks or terminals in a process to data, enabling static storage to respond to more data read requests simultaneously, and based on shared memory, different processes can implement collaborative processing and display of data by multiple tasks or terminals on the server side, avoiding data trampling problems caused by the use of data in static storage between multiple processes. SUMMARY

[0004] In view of the defects in the prior art, the present application aims to provide a shared memory system and an implementation method.

[0005] According to the present application, a shared memory system is provided, comprising: An SVMA module is configured to allocate a shared virtual address interval SVMA of shared memory for each process participating in communication, and to implement fine-grained and strongly isolated shared memory by using the shared virtual address interval SVMA. The shared virtual address interval SVMA comprises a plurality of sharing slots, n sharing slots are selected as n Connections based on the plurality of sharing slots, and the n Connections are randomly distributed within the shared virtual address interval SVMA; processes with the same IPC requirement share the same Connection. The Connection comprises a plurality of sharing sub-slots Sharing Subslot. A memory manager module is configured to perform fine-grained management on the sharing sub-slots Sharing Subslot by using a user-mode memory manager. The user-mode memory manager is a multi-level linked list memory manager, which is configured to divide the sharing sub-slots Sharing Subslot into a plurality of memory pools with different sizes, and organize the memory pools by using a linked list.

[0006] Preferably, the SVMA module comprises: all pages of a physical shared memory region are mapped into the shared virtual address interval SVMA of shared memory allocated for each process participating in communication. The shared virtual address interval SVMA is not continuously mapped, and only part of the shared virtual address interval SVMA is mapped with the physical memory.

[0007] Preferably, the Connection is randomly and discontinuously distributed in the shared virtual address interval SVMA; when a process is created or joins a Connection, a Connection key is randomly generated, and the generated Connection key is transmitted to a user process; the user process obtains the virtual address of the Connection, an associated random seed Seed, and the number of valid mappings in the Connection by using ioctl to request the kernel; the random seed Seed corresponds to a random seed Seed for each Connection.

[0008] Preferably, when the number of Connections in the shared virtual address interval SVMA is insufficient, the SVMA region is expanded, the number of Connections is increased, and the shared page table entry is modified at the same time.

[0009] Preferably, different Connections are set with different sparseness satisfying preset requirements, and the Connections with different sparseness are allocated according to requirements.

[0010] Preferably, the shared sub-slots Sharing Subslot are randomly and discontinuously distributed in the Connections. When a process initializes a Connection, a random number is generated according to a random seed Seed; and the layout of the shared sub-slots Sharing Subslot in the Connection is determined according to the generated random number.

[0011] Preferably, when the two generated random numbers in a Connection conflict, the pseudo-random number is generated again until the random number without conflict appears. Or the process maintains a bitmap of memory allocation for each Connection; when a legal mapping position is generated by using the random seed Seed, the bitmap is used to check the current memory allocation to ensure that the memory region is not allocated, and is marked; if a conflict occurs, a new address is generated by using the Seed until no conflict occurs.

[0012] Preferably, the memory manager module includes: when a process allocates memory, the memory closest to the demand is taken out from the memory pool; when the memory pool is exhausted, the multi-level linked list memory manager applies for the shared sub-slots Sharing Subslot again and pools them.

[0013] Preferably, the system further includes: a shmland kernel module for realizing fine-grained high-performance memory isolation of the extended Linux kernel through address randomization and asynchronous memory management. The address randomization includes: for a process group requiring IPC through shared memory, a Connection is applied for and allocated by shmland, the base address corresponding to the current Connection and the random seed Seed are synchronously provided, and the processes in the current process group generate the legal first address of all the shared sub-slots Sharing Subslot in the current Connection by using a pseudo-random number generator according to the random seed Seed. The asynchronous memory management includes that all sharing subslots in a Connection are not all mapped when the Connection is created, but only a preset number of sharing subslots are mapped; a thread is started in the kernel through shmland to scan the use of the sharing subslots in each Connection, and a plurality of subslots are mapped again for the Connection before the mapped sharing subslots of the Connection are used up; and correspondingly, when the number of unused sharing subslots of the Connection is large and meets a preset requirement, shmland cancels the mapping of the idle subslots. Meanwhile, a meta page is arranged in the Connection to record the use of the sharing subslots, and shmland performs memory management through the meta page.

[0014] According to the shared memory system implementation method provided by the application, the following steps are included. Step S1: allocating a shared virtual address interval SVMA of shared memory for each process participating in communication by using an SVMA module; and realizing fine-grained and strong-isolated shared memory by using the shared virtual address interval SVMA; wherein the shared virtual address interval SVMA includes a plurality of sharing slots, n sharing slots are selected as n Connections based on the plurality of sharing slots, and the n Connections are randomly distributed in the shared virtual address interval SVMA; processes with the same IPC requirement share the same Connection; and the Connection includes a plurality of sharing subslots. Step S2: performing fine-grained management on the sharing subslots by a memory manager module through a user-mode memory manager. The user-mode memory manager is a multi-level linked list type memory manager, and the sharing subslots are divided into a plurality of memory pools with different sizes by using the multi-level linked list type memory manager, and are organized by using a linked list.

[0015] Compared with the prior art, the application has the following beneficial effects: 1. Fine-grained memory sharing, allowing flexible creation of shared memory among different processes, and supporting different granularity of memory size. 2. Strong isolation of shared memory, malicious processes cannot access the shared memory data of other processes; memory out-of-bounds vulnerabilities cannot access the shared memory data of other processes; 3. High-performance memory management, shared memory allocation, release, and other operations, single-time consumption less than 300 cycles; shared memory access performance loss geometric mean ≤ 5%; in the SPEC CPU2006 benchmark test set, the performance loss geometric mean ≤ 5%. BRIEF DESCRIPTION OF DRAWINGS

[0016] Other features, objects, and advantages of the application will become more apparent from the following detailed description of non-limiting embodiments, read in conjunction with the accompanying drawings: Figure 1 Figure 1 is a schematic diagram of a shared memory system.

[0017] Figure 2 Figure 2 is an SVMA management flowchart.

[0018] Figure 3 Figure 3 is a Connection allocation flowchart.

[0019] Figure 4 Figure 4 is a Connection recycling flowchart.

[0020] Figure 5 Figure 5 is a Sharing Subslot management flowchart.

[0021] Figure 6 Figure 6 is a fine-grained memory management flowchart. DETAILED DESCRIPTION

[0022] The application will be described in detail below with specific embodiments. The following examples will help those skilled in the art to further understand the application, but do not limit the application in any form. It should be noted that for those skilled in the art, without departing from the concept of the application, a number of changes and improvements can be made. These are within the scope of the present application.

[0023] Example 1 According to the shared memory system and implementation method provided by the application, the overall goal is to implement a high-performance fine-grained strong isolation shared memory mechanism; the application constructs a shared virtual memory space between processes involved in inter-process communication, and adds regions that do not exist in the physical memory mapping in the virtual address space. If these non-mapping regions are accessed, they will be identified as malicious behavior or program bugs, thus terminating the process. Similar to Address Space Layout Randomization (ASLR), the addresses with legal mappings are randomly determined, so it is difficult for malicious attackers to directly guess the location of the legal mappings.

[0024] The shared memory system, such as Figure 1 As shown, each process participating in communication has a virtual address interval dedicated to shared memory, a Sharing Virtual Memory Area, SVMA, and multiple connections are randomly distributed in the SVMA, with each randomization of a connection corresponding to a random seed, Seed. Processes with the same IPC requirements share the same connection. The connection has multiple sharing subslots. In order to manage the sharing subslots with fine memory granularity, the application introduces a user-mode memory manager. In addition, the application introduces a Linux kernel module, shmland, which realizes the purpose of expanding the fine-grained high-performance memory isolation capability of the Linux kernel through address randomization and asynchronous memory management. Among them, the connection is a basic unit of inter-process communication; a large piece of space of the connection is divided into multiple sharing subslots, which can be managed in detail.

[0025] Specifically, the shared memory system comprises: The SVMA module: each process has a virtual address interval dedicated to shared memory, and the virtual address region dedicated to shared memory is called SVMA, and all pages of the physical shared memory region are mapped to the SVMA of each process.

[0026] The SVMA is not like the traditional shared virtual memory, and its internal is not continuously mapped, but only part of it establishes a mapping relationship with the physical memory. Therefore, the program cannot randomly access the SVMA, but must follow the specification provided by the application to correctly access the data in the SVMA. When a malicious process or a vulnerability process appears, it will be limited because it does not comply with the specification, and the shadow caused by the process will be limited. The Connection module: the SVMA is divided into multiple SharingSlot, and several of them are selected as Connection, that is, Connection is a special SharingSlot, and only Connection establishes a memory mapping, and accessing the Sharing Slot that is not Connection will cause Page Fault.

[0027] Processes with IPC requirements share a connection, and a process can have multiple connections.

[0028] Connection in SVMA presents a randomized, discontinuous distribution, which is randomized by the Linux kernel and invisible to user processes; specifically, the Linux kernel has a random number generator that can provide randomization functions. The Linux kernel allocates a Connection available from the SVMA according to an internally maintained data structure, and randomly generates a Connection key Connection Key to inform the user process. The user process can obtain the virtual address of the Connection, the associated Seed, and the number of valid mappings in the Connection from the kernel through ioctl by means of the Connection key. The Connection Key is a secret of the process associated with the Connection, and other unrelated processes cannot obtain the Connection Key corresponding to the Connection. Processes that do not belong to the process group cannot determine the starting address of the Connection, nor do they have the random number seed Seed, so they cannot access the shared data in the Connection. If a process that does not belong to the process group attempts to scan the entire SVMA region, it will fail due to illegal mappings and the presence of Guard Pages. The operating system is responsible for ensuring that the Subslot in the Connection has a legal memory mapping.

[0029] In this embodiment, when the number of existing Connections in the SVMA is insufficient, it also means that the size of the physical memory used for sharing is insufficient, and the operating system needs to expand the SVMA region and increase the number of Connections. Because these processes share an L0 or L1 page table entry, a large number of page table modifications are not required for each process, and only one modification is required in the shared page table. At the same time, the operating system only needs to add page table entries, and this process does not involve remapping, but only increases the mapping, so there is no need to flush the TLB.

[0030] At the same time, the operating system can set different sparseness for different Connections, that is, the proportion of pages that actually have mappings in a SharingSlot. When a process applies for a Connection with another process, it can make a specific sparseness requirement. The higher the sparseness, the higher the security, and it is more difficult for malicious attackers and bug programs to directly access the valid mapping area. The operating system can allocate a Connection according to the specific sparseness requirement.

[0031] Sharing Subslot module: Connection is divided into several smaller areas, each of which is called a Sharing Subslot. Only Sharing Subslots establish memory mapping, and accessing non-Sharing Subslots will cause a Page Fault. The head and tail of a Sharing Subslot each have a Guard Page, and accessing them will also trigger a Page Fault, preventing out-of-bounds access.

[0032] Sharing Subslots are also randomly distributed and discontinuous in the Connection. When a process initializes a connection, it generates a random number based on the Seed, and uses the random number to determine the location of the next available subslot. Different processes generate pseudo-random numbers using the same algorithm, and when the Seed is determined, the same result is generated. Therefore, even if different processes have the same Seed, they can generate the same random sequence. The layout of the Sharing Subslots is generated based on this random number. This property ensures that different processes can access the same address when accessing the randomized memory layout.

[0033] If there is a conflict between the two random numbers generated in a Connection, the pseudo-random number will be generated again until a random number without conflict is generated. However, this situation rarely occurs in pseudo-random numbers, and the probability is extremely small. To eliminate potential conflicts, the process maintains a bitmap of memory allocation for each Connection. When generating a legal mapping location using the Seed, the bitmap is used to check the current memory allocation to ensure that the memory area has not been allocated and marked. If a conflict occurs, i.e., the generated address has been used before, the Seed is used to generate a new address until there is no conflict.

[0034] In this embodiment, the kernel thread determines whether to map or unmap the Subslot by monitoring the Subslot state array. The kernel thread can choose different strategies to manage the state of the Subslots. An aggressive allocation strategy can make most of the Subslots mapped, and the delay of user access to the Subslots is lower. A conservative allocation strategy can make the idle Subslots be recycled in time, avoiding memory fragmentation.

[0035] Fine-grained memory manager module: Because the allocation mapping granularity is coarse, and the Subslot is the finest granularity of 4K pages (effective mapping part), if a Subslot is newly allocated every time memory is needed, a large amount of memory will be wasted. Therefore, the process can use a user-mode memory allocator inside each Subslot for finer-grained memory management, and further allocate continuous memory into small memory objects, thereby improving the utilization. Each Connection corresponds to a memory manager.

[0036] The memory manager implemented in the application is a multi-level linked list memory manager similar to slab, which divides the Subslot into multiple memory pools of different sizes and organizes them with a linked list. When the process allocates memory, it takes memory from the memory pool closest to the demand. When the memory pool is exhausted, the memory manager will apply for a Subslot again and pool it. This design makes the time complexity of memory allocation and release very efficient.

[0037] shmland kernel module: shmland is a Linux kernel module implemented in the application, which extends the ability of the Linux kernel for fine-grained shared memory isolation.

[0038] For process groups that need to perform IPC through shared memory, they will apply for a Connection from shmland, and the operating system will provide them with the base address and Seed corresponding to the Connection. The processes in the process group can generate the legal starting address of all Subslots in the Connection by using a pseudo-random number generator according to the Seed, without entering the kernel or modifying the process page table.

[0039] In order to improve performance and physical memory utilization, the application designs an asynchronous memory management mechanism. All Subslots in a Connection will not be mapped at the time of Connection creation, but only part of the subslots will be mapped. shmland will start a thread in the kernel to scan the usage of Subslots in each Connection, and map multiple Subslots for the Connection again before the mapped Subslots of the Connection are used up; correspondingly, when there are many unused Subslots in the Connection, shmland will cancel the mapping of the idle Subslots to avoid wasting physical memory.

[0040] In order to make shmland to carry on asynchronous memory management, there is a meta page in Connection to record the use of Subslot, and shmland can check the meta page to carry on memory management.

[0041] Embodiment 2 Embodiment 2 is a preferred embodiment of Embodiment 1 According to the shared memory system implementation method provided by the application, the method comprises an SVMA management process, a Connection allocation process, a Connection recycling process, a Sharing Subslot management process and a fine-grained memory management process.

[0042] The SVMA management process comprises the following steps: Figure 2 The Connection allocation process comprises the following steps: Step 1.1: The kernel pre-allocates physical memory as shared memory; Step 1.2: The kernel registers the device file / dev / shmland for user use; Step 1.3: The user opens the / dev / shmland file through an open system call; Step 1.4: The kernel creates an SVMA in the user virtual address space; Step 1.5: The user performs Connection-related operations on the SVMA through an ioctl; Step 1.6: The user closes the / dev / shmland file through a close system call; Step 1.7: The kernel unregisters the SVMA in the user virtual space.

[0043] The Connection allocation process comprises the following steps: Figure 3 The Connection recycling process comprises the following steps: Step 2.1: The user applies for a Connection to the kernel through an ioctl; Step 2.2: The kernel randomizes the start address of the Connection; Step 2.3: The kernel randomizes the Connection Key; Step 2.4: The kernel initializes the meta page of the Connection and maps it to the user space; Step 2.5: The user obtains the start address and Key of the Connection from the kernel through an ioctl; Step 2.6: The user creates a fine-grained memory manager; Step 2.7: The user registers the meta page to the memory manager; Step 2.8: User calls memory manager to allocate memory.

[0044] The Connection recycling process, as shown in Figure 4 includes: Step 3.1: User calls memory manager to release all memory; Step 3.2: User informs kernel to recycle Connection through ioctl; Step 3.3: Kernel unregisters corresponding Connection Key; Step 3.4: Kernel unregisters Connection virtual address space mapping; Step 3.5: Kernel recycles Connection.

[0045] The Sharing Subslot management process, as shown in Figure 5 includes: Step 4.1: User checks meta page to see if there is a free mapped Subslot; Step 4.2: User allocates Subslot; Step 4.3: User releases Subslot; Step 4.4: Kernel timely scans meta page and finds missing mapped Subslot; Step 4.5: User applies to kernel for mapping Subslot through ioctl; Step 4.6: Kernel maps Subslot for user; Step 4.7: Kernel scans meta page and cancels mapping of free Subslot.

[0046] The fine-grained memory management process, as shown in Figure 6 includes: Step 5.1: Memory manager registers meta page; Step 5.2: Memory manager creates multiple memory pools, each representing different size of memory; Step 5.3: User applies for memory of specific size; Step 5.4: Memory manager selects different memory pool according to size of memory applied by user; Step 5.5: Whether memory in memory pool is sufficient; Step 5.6: Memory manager takes out memory from memory pool and gives it to user; Step 5.7: Memory manager allocates Subslot and pools it; Step 5.8: User releases memory; Step 5.9: The memory manager puts the user released memory back into the corresponding memory pool.

[0047] Those skilled in the art will appreciate that, in addition to implementing the system, device and each module thereof provided by the present application in the form of pure computer readable program code, the system, device and each module thereof provided by the present application can also be implemented in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers and embedded microcontrollers, etc. by logically programming the method steps. Therefore, the system, device and each module thereof provided by the present application can be considered as a hardware component, and the modules included therein for implementing various programs can also be considered as structures within the hardware component; the modules for implementing various functions can also be considered as both software programs for implementing methods and structures within hardware components.

[0048] The specific embodiments of the present application are described above. It needs to be understood that the present application is not limited to the specific embodiments described above, and various changes or modifications can be made by those skilled in the art within the scope of the claims, which does not affect the essential content of the present application. The embodiments of the present application and the features in the embodiments can be combined with each other in any manner without conflict.

Claims

1. A shared memory system, characterized by, The application comprises: an SVMA module for allocating a shared virtual address interval SVMA of shared memory for each process participating in communication, and realizing fine-grained and strongly isolated shared memory by using the shared virtual address interval SVMA; the shared virtual address interval SVMA comprises a plurality of sharing slots, n sharing slots are screened as n Connections based on the plurality of sharing slots, and the n Connections are randomly distributed within the shared virtual address interval SVMA; processes with the same IPC requirement share the same Connection; the Connection comprises a plurality of sharing sub-slots Sharing Subslot; a memory manager module for fine-grained management of the sharing sub-slots Sharing Subslot by using a user-mode memory manager; the user-mode memory manager is a multi-level linked list memory manager, the sharing sub-slots Sharing Subslot are divided into a plurality of memory pools with different sizes by using the multi-level linked list memory manager, and are organized by using a linked list.

2. The shared memory system of claim 1, wherein, the SVMA module comprises that all pages of a physical shared memory region are mapped into a shared virtual address interval SVMA of shared memory allocated for each process participating in communication; the shared virtual address interval SVMA is not continuously mapped, and only part of the shared virtual address interval SVMA has a mapping relationship with the physical memory.

3. The shared memory system of claim 1, wherein, the Connection is randomly and discontinuously distributed in the shared virtual address interval SVMA; when a process creates or joins a Connection, a Connection key is randomly generated, and the generated Connection key is transmitted to a user process; the user process obtains the virtual address of the Connection, the associated random seed Seed, and the number of valid mappings in the Connection by using ioctl to ask the kernel; 4. The shared memory system of claim 1, wherein, when the number of Connections in the shared virtual address interval SVMA is insufficient, the SVMA region is expanded, the number of Connections is increased, and the shared page table entry is modified at the same time.

5. The shared memory system of claim 1, wherein, different Connections are set to have different sparsenesses satisfying preset requirements, and the Connections with different sparsenesses are allocated according to requirements.

6. The shared memory system of claim 1, wherein, the sharing sub-slots Sharing Subslot are randomly and discontinuously distributed in the Connection; when a process initializes a Connection, a random number is generated according to a random seed Seed; and the layout of the sharing sub-slots Sharing Subslot in the Connection is determined according to the generated random number.

7. The shared memory system of claim 1, wherein, When the random numbers generated twice in a Connection conflict, the pseudo-random number is generated again until the random number without conflict appears; Or the process maintains a bitmap of memory allocation for each Connection, and checks the current memory allocation using the bitmap when generating a legal mapping position using the random seed Seed, to ensure that the memory area has not been allocated and is marked; If there is a conflict, continue to generate a new address using Seed until there is no conflict.

8. The shared memory system of claim 1, wherein, The memory manager module includes: when the process allocates memory, the memory closest to the demand is taken out from the memory pool; when the memory pool is exhausted, the multi-level linked list memory manager applies for a Sharing Subslot again and pools it.

9. The shared memory system of claim 1, wherein, The system also includes: a shmland kernel module for expanding the fine-grained high-performance memory isolation of the Linux kernel through address randomization and asynchronous memory management; The address randomization includes: for the process group that needs to perform IPC through shared memory, a Connection is applied for allocation through shmland, the base address corresponding to the current Connection and the random seed Seed are synchronously provided, and the processes in the current process group generate the legal first address of all Sharing Subslots in the current Connection using the pseudo-random number generator according to the random seed Seed; The asynchronous memory management includes: all Sharing Subslots in a Connection are not all mapped at the time of Connection creation, but only a preset number of Sharing Subslots are mapped; through shmland, a thread is started in the kernel to scan the use of the Sharing Subslots in each Connection, and multiple Subslots are mapped for the Connection again before the mapped Sharing Subslots of the Connection are used up; correspondingly, when the number of unused Sharing Subslots of the Connection is large and meets the preset requirement, shmland cancels the mapping of the idle Subslots; Meanwhile, a meta page is arranged in the Connection to record the use of the Sharing Subslots, and shmland manages the memory through the meta page.

10. A method for implementing a shared memory system, characterized by, It includes: Step S1: allocating a shared virtual address interval SVMA of shared memory for each process participating in communication using the SVMA module; Step S2: using the shmland module to provide the base address corresponding to the current Connection and the random seed Seed to the process group, and generating the legal first address of all Sharing Subslots in the current Connection using the pseudo-random number generator according to the random seed Seed; The shared memory is implemented by using a shared virtual address interval SVMA to achieve fine-grained strong isolation, wherein the shared virtual address interval SVMA comprises a plurality of sharing slots, n sharing slots are screened as n connections based on the plurality of sharing slots, and the n connections are randomly distributed inside the shared virtual address interval SVMA; processes with the same IPC requirement share the same connection; the connection comprises a plurality of sharing sub-slots SharingSubslot. In step S2, the memory manager module is used to perform fine-grained management on the sharing sub-slots SharingSubslot by a user-mode memory manager. The user-mode memory manager is a multi-level linked list memory manager, the sharing sub-slots SharingSubslot are divided into a plurality of memory pools with different sizes by using the multi-level linked list memory manager, and the memory pools are organized by using a linked list.

Images