A non-intrusive Linux memory barrier modification method and information system

Abstract

This application relates to the field of computer technology, providing a non-intrusive Linux memory barrier modification method and system. The method is applied to scenarios where an information system is migrated from a strong memory model chip architecture to a weak memory model chip architecture. Specifically, it includes: in the newly added adaptation layer, determining the target system calls invoked by the component layer, and constructing a rewritten function with the same name for each target system call. The rewritten function sequentially includes a first memory barrier instruction, an instruction to call the original target system call, and a second memory barrier instruction; compiling the rewritten function into a dynamic link library; and when the business process starts, preferentially loading the custom dynamic library by preloading environment variables to hijack system calls, so that the operating system's dynamic linker redirects the component layer's calls to the target system calls to the rewritten function. This application achieves complete decoupling of business logic and adaptation logic by implanting a memory barrier at the system call layer without modifying the business layer and component layer code.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to a non-intrusive Linux memory barrier modification method and information system. Background Technology

[0002] In information systems with multi-core CPU architecture, due to CPU cache coherency and compiler instruction reordering, Linux memory out-of-order issues can easily occur when multiple threads / processes concurrently access shared memory, leading to abnormal program execution logic. This problem is particularly prominent when information systems are ported across different chip architectures.

[0003] Classic CPU L3 cache architecture, such as Figure 1 As shown, each core has its own L1 and L2 caches, while multiple cores within a single chip share the L3 cache. When multiple cores access shared memory data simultaneously, if one core modifies the cache data, other cores may still retain the old data, directly causing data consistency issues.

[0004] To improve program execution efficiency, compilers perform instruction reordering optimizations without altering single-threaded semantics. While this optimization has no impact in a single-threaded environment, it disrupts the execution order of memory operations in multi-threaded / multi-process shared memory scenarios, further exacerbating memory out-of-order issues. Furthermore, different chip architectures employ different memory models: x86 and similar architectures use a strong memory model (SC), which imposes fewer restrictions on memory operation reordering, and the instruction execution order is highly consistent with the code order; some architectures use TSO (Total Store Order), a weak memory model (WMM) that allows for more memory operation reordering in exchange for performance gains. This amplifies the impact of memory out-of-order issues when porting systems across different memory model architectures.

[0005] To address memory out-of-order issues, the industry commonly employs memory barrier synchronization mechanisms. As a core means of controlling the order of memory operations, these mechanisms can, at the hardware level, pause the processor pipeline to ensure that memory operations in front of the barrier are completed and visible to other processors; and at the compiler level, they can prevent instruction reordering, thereby guaranteeing the order of memory operations in a multi-process / threaded environment.

[0006] A classic code hierarchy architecture diagram of a multi-process shared memory information system is shown below. Figure 2As shown, it is mainly divided into three layers: the business layer, the component layer, and the system call layer. The business layer consists of several business processes that communicate with each other through shared memory. The component layer is a set of custom shared memory containers that implement commonly used containers that can be safely used in a multi-process environment, such as vector, list, and map. The bottom layer is the system call layer, which implements various shared memory containers by calling Linux system calls. The main operation methods include interfaces such as shmget, shmat, and shmctl.

[0007] Traditional memory barrier modification methods involve intrusive code modifications at the business or component layer based on the above architecture. This means manually inserting memory barrier instructions before and after read / write operations on shared memory containers. Figure 3 This is a flowchart illustrating a method of code modification that intrudes into the business layer. The dashed boxes represent memory barrier instructions that need to be added during the modification process.

[0008] This invasive modification method has four major flaws, which are particularly prominent in cross-architecture system porting scenarios: 1. High risk of system changes: The business logic and memory barrier adaptation code are tightly coupled. Modification of either one may cause functional abnormalities in the other, making the originally stable system vulnerable. 2. Low development efficiency: When developing new features or fixing issues, developers need to additionally understand and maintain the adaptation code. Manually adding memory barrier instructions is also prone to omissions, which distracts from core development efforts. 3. Test difficulty increases dramatically: Testing work needs to verify the correctness of business logic and the compatibility of memory barriers at the same time. Existing business test cases cannot cover the modified logic, and the cost of test case design and execution increases significantly. 4. Hinders technological evolution: The adaptation code deeply intrudes into the business layer and component layer. When the system needs to be migrated to a new architecture or technology stack for upgrade, it is difficult to achieve a smooth transition and a large number of intrusive modifications need to be repeated. Summary of the Invention

[0009] To help solve the above-mentioned technical problems, this application provides a non-intrusive Linux memory barrier modification method and information system.

[0010] Firstly, this application provides a non-intrusive Linux memory barrier modification method for information systems ported from a first memory model chip architecture to a second memory model chip architecture. The first memory model chip architecture is a strong memory model chip architecture, and the second memory model chip architecture is a weak memory model chip architecture. The strong memory model chip architecture includes x86 or x86-64 architecture, and the weak memory model chip architecture includes ARM architecture. The information system includes a business layer, a component layer, and a system call layer. The component layer achieves inter-process communication by calling Linux shared memory system calls in the system call layer. The non-intrusive Linux memory barrier modification method adds an adaptation layer between the component layer and the system call layer, and implants a memory barrier through the adaptation layer, specifically including: S1: In the adaptation layer, identify at least one target system call invoked by the component layer, where the target system call is part or all of the Linux shared memory system calls; S2: In the adaptation layer, for each target system call, a rewritten function with the same name as the target system call is constructed based on the operation semantics and data flow of that target system call; the execution logic inside the rewritten function includes, in sequence: Execute the first memory barrier instruction, i.e., the write memory barrier instruction. The type of the first memory barrier instruction is configured to ensure that the input parameter preparation operations and the previous memory state before calling the target system call are globally visible to the system. Execute the original instruction that invoked the target system call; Execute the second memory barrier instruction, either a read memory barrier instruction or a full memory barrier instruction. The type of the second memory barrier instruction is configured to ensure that the return result and shared memory status after the target system call is executed are immediately visible to subsequent business process operations. When the target system call is shmget or shmat, the second memory barrier instruction is a read memory barrier instruction; when the target system call is shmdt, the second memory barrier instruction is a full memory barrier instruction.

[0011] S3: Compile the rewritten functions in the adaptation layer into a dynamic link library; S4: When starting the business process of the information system, the dynamic link library of the adaptation layer is loaded preferentially by preloading environment variables. This causes the operating system's dynamic linker to prioritize the use of the rewritten function in the adaptation layer when parsing the component layer's call to the target system, thereby intercepting the component layer's call to the target system and redirecting the call to the rewritten function.

[0012] The preloaded environment variable is the LD_PRELOAD environment variable, which is used to hijack Linux user-space system calls.

[0013] The target system call is a Linux shared memory operation-related system call, including at least one of shmget, shmat, shmdt, and shmctl.

[0014] Constructing the rewritten function also includes: obtaining the original function address of the target system call using the dlsym function and the RTLD_NEXT handle; the steps of compiling into a dynamic link library include using the gcc compiler with the -fPIC and -shared options, and linking the dl library.

[0015] Memory barrier instructions are implemented through the atomic_thread_fence function and defined as the following macros: the function parameter for a read memory barrier is memory_order_acquire, the function parameter for a write memory barrier is memory_order_release, and the function parameter for a full memory barrier is memory_order_seq_cst.

[0016] Secondly, this application provides an information system, wherein the system is modified using the non-intrusive Linux memory barrier modification method described in any one of the first aspects, comprising: The business layer contains multiple business processes used to implement business logic; The component layer, located below the business layer, provides a custom shared memory container for the business layer to perform inter-process communication, and implements the operation of the custom shared memory container by calling the Linux shared memory system calls in the system call layer. The system call layer provides the underlying Linux shared memory system call interface; The adaptation layer, located between the component layer and the system call layer, includes a dynamic link library containing a rewrite function that rewrites at least one target system call. The rewrite function has the same name as the original system call, and a first memory barrier instruction and a second memory barrier instruction are inserted before and after the original system call function is called, respectively. When the business process starts, the dynamic link library of the adaptation layer is loaded first by preloading environment variables, so that the component layer's calls to the target system are automatically intercepted by the operating system's dynamic linker and redirected to the rewritten function of the adaptation layer.

[0017] The core of this system lies in the addition of an adaptation layer between the original business layer, component layer, and system call layer. This adaptation layer exists in the form of a dynamic link library. By intercepting the component layer's calls to specific system calls, it implants necessary memory barriers without modifying the business layer and component layer code, thereby constructing a loosely structured, decoupled layered information system.

[0018] In summary, this application achieves non-intrusive modification of memory barriers during cross-chip architecture porting of Linux systems through architectural decoupling and shifting the memory barrier modification layer downwards. Compared with traditional invasive methods, it has the following core advantages: 1. The adaptation layer is completely decoupled from the business layer and component layer. Modifications to business logic will not affect the memory barrier adaptation code, and iterative upgrades of the adaptation layer will not cause abnormalities in the original business functions, thus fundamentally solving the system vulnerability problem caused by coupling. 2. Developers do not need to worry about the logic related to memory barrier adaptation, and can focus entirely on the development, iteration and problem fixing of business functions, avoiding the omission problem of manually adding memory barriers and greatly improving the efficiency of core development work; 3. The testing process can independently verify the compatibility of business logic and memory barriers. The test cases of the original business layer do not need to be modified. Only the adaptation layer needs to be tested for compatibility, which greatly reduces the cost of test case design and execution. 4. The adaptation layer is an independent modular design. When the system needs to be ported to a new chip architecture or upgraded in terms of technology stack, only the logic of the adaptation layer needs to be adjusted. There is no need to change the code of the business layer and component layer, so as to achieve a seamless transition of the system across architectures. 5. The dynamic library-based adaptation layer can be directly reused in cross-architecture porting projects of the same type of Linux system, without the need for repeated intrusive code modifications for different business systems, which greatly reduces the overall transformation and maintenance costs. Attached Figure Description

[0019] Figure 1 The first relevant figure is shown in the background art; Figure 2 The second related figure is shown in the background art; Figure 3 The third related figure is shown in the background art; Figure 4 This is a diagram of the non-intrusive modification technology architecture of this application; Figure 5 This is a flowchart illustrating the execution of the rewritten function in this application. Detailed Implementation

[0020] The present application will be further described below with reference to the accompanying drawings. The principles of the present application are very clear to those skilled in the art. It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the present application.

[0021] To facilitate understanding of the technical solution of this application, the following explanations are provided for the English terms appearing in the text: Linux: An open-source Unix-like operating system kernel widely used in servers, embedded systems, and desktop environments.

[0022] CPU (Central Processing Unit): The core component of a computer system, responsible for executing program instructions. In a multi-core CPU system, each core can execute tasks independently.

[0023] L1 / L2 / L3 cache: A multi-level high-speed cache inside the CPU, used to reduce the latency of accessing main memory. Typically, each core has its own L1 and L2 cache, while multiple cores share the L3 cache.

[0024] Core: An independent processing unit inside the CPU. A multi-core CPU can execute multiple threads or processes simultaneously.

[0025] Sequential Consistency (SC): A strong memory model that requires all memory operations to be executed in program order, and that the order is consistent across all processors. The x86 / x86-64 architecture uses a strong memory model similar to SC.

[0026] Total Store Order (TSO): A weak memory model that allows some memory operations to be reordered, but guarantees the order of write operations (store). It is a type of weak memory model.

[0027] WMM (Weak Memory Model): A memory model that allows compilers and processors to reorder memory operations more frequently to improve performance, but requires developers to explicitly add synchronization mechanisms to ensure correctness. The ARM architecture uses a weak memory model.

[0028] x86 / x86-64: Processor architectures used by Intel and AMD, belonging to the Complex Instruction Set Computing (CISC) architecture, which typically implements a strong memory model.

[0029] ARM: A processor architecture widely used in mobile devices and servers. It belongs to the Reduced Instruction Set Computing (RISC) architecture and typically implements a weak memory model.

[0030] shmget, shmat, shmdt, and shmctl are four core system calls in Linux used for shared memory operations. shmget is used to create or acquire a shared memory segment; shmat is used to attach a shared memory segment to a process's address space; shmdt is used to detach a shared memory segment; and shmctl is used to control shared memory segments (such as deleting or querying their status).

[0031] LD_PRELOAD: An environment variable of the Linux dynamic linker used to specify dynamically shared libraries that are loaded first before the program runs. LD_PRELOAD can be used to hook library function calls and replace them with user-defined functions.

[0032] `dlsym`: A Linux dynamic link library function used to find the address of a symbol (function or variable) in a shared library. It is often used in conjunction with `RTLD_NEXT` to obtain the address of the next library where the symbol appears.

[0033] RTLD_NEXT: A special handle for the dlsym function, indicating the next shared library after the current library where the target symbol appears, used to call the original function during function hijacking.

[0034] atomic_thread_fence: An atomic operation function provided in the C11 standard, used to insert memory barriers between threads to ensure the order of memory operations. Its parameter specifies the barrier type.

[0035] memory_order_acquire: A C11 memory order enumeration value used for reading memory barriers. It ensures that read operations after the barrier are not reordered to before the barrier, and that write operations before the barrier are visible to the current thread.

[0036] memory_order_release: A C11 memory order enumeration value used to write memory barriers, ensuring that write operations before the barrier are not reordered to after the barrier, and that these write operations are visible to other threads.

[0037] memory_order_seq_cst: A C11 memory order enumeration value used for complete memory barriers, providing a guarantee of order consistency, ensuring that all memory operations before and after the barrier cannot be rearranged.

[0038] gcc: GNU compiler suite, used in this application to compile dynamic link libraries.

[0039] -fPIC: A gcc compilation option that generates position-independent code for compiling shared libraries.

[0040] -shared: A gcc compilation option that instructs the generation of a dynamic link library.

[0041] -ldl: A gcc linking option that links the dl library (libdl) to enable the use of dynamic linking functions such as dlsym.

[0042] vector, list, and map are commonly used containers in the C++ Standard Template Library (STL), corresponding to dynamic arrays, doubly linked lists, and associative maps, respectively. In this application, they are provided as examples of custom shared memory containers at the component layer.

[0043] Combination Figure 4 and Figure 5 It is understood that this information system includes a business layer, a component layer, an adaptation layer, and a system call layer. The business layer contains multiple business processes used to implement specific business logic; the component layer is located below the business layer and provides custom shared memory containers such as vector, list, and map for inter-process communication within the business layer. The component layer implements the underlying operations of these containers by calling Linux shared memory system calls in the system call layer (in this embodiment, these can be one or more of shmget, shmat, shmdt, and shmctl); the adaptation layer is a newly added independent module in this application, located between the component layer and the system call layer, and is a dynamic link library containing functions with the same name that overwrite the target system calls; the system call layer is the underlying system call interface provided by the Linux kernel. When the business process starts, the dynamic library of the adaptation layer is loaded preferentially by preloading environment variables (LD_PRELOAD in this embodiment). This causes the component layer's calls to the target system calls to be automatically redirected by the operating system's dynamic linker to the rewritten function in the adaptation layer, thereby "hijacking" the system call and completing the implantation of the memory barrier without modifying the business layer and component layer code.

[0044] The core innovations of this application lie in architectural decoupling and non-intrusive modification of the system call layer. It abandons the traditional intrusive code modifications at the business / component layers, utilizing Linux user-space system call hijacking technology to uniformly add memory barrier instructions at the system call layer. Simultaneously, an adaptation layer is added between the original component layer and the system call layer to specifically handle memory barrier modification logic, achieving complete decoupling between the business layer, component layer, and adaptation layer. Existing business and component code can complete memory barrier adaptation without any modifications. The overall technical architecture of this application represents a non-intrusive extension of the original layers.

[0045] This application combines existing technologies to innovatively adapt Linux user-space system call hijacking (LD_PRELOAD) and memory barrier instructions, applying them to memory barrier modification scenarios during cross-architecture Linux system porting. The key implementation consists of two main parts: rewriting system calls and process startup hijacking. The specific key implementation steps are divided into three steps: Step 1: Define standardized memory barrier instruction macros.

[0046] Based on the three common types of memory barriers for processors (read, write, and complete), and combined with the characteristics of Linux shared memory operations, standardized memory barrier macros are defined to adapt to the memory model requirements of different chip architectures, ensuring the orderliness and visibility of memory operations. Read memory barrier: Only ensures the order of memory read operations, atomic_thread_fence(memory_order_acquire); Write memory barrier: only ensures the order of memory write operations, atomic_thread_fence(memory_order_release); Complete memory barrier: Ensures that all memory read and write operations before the barrier are completed before executing read and write operations after the barrier, atomic_thread_fence(memory_order_seq_cst).

[0047] This application defines macros for three types of memory barrier instructions: #define READ_BARRIER() atomic_thread_fence(memory_order_acquire) #define WRITE_BARRIER() atomic_thread_fence(memory_order_release) #define FULL_BARRIER() atomic_thread_fence(memory_order_seq_cst) In this embodiment, the aforementioned barrier macros are based on the C11 standard atomic operation library, exhibiting excellent cross-platform compatibility. Regardless of the target chip architecture—x86, ARM, or other types—these macros can generate corresponding memory barrier instructions, ensuring that this method is applicable to porting scenarios from any strong memory model architecture (such as x86, x86-64) to any weak memory model architecture (such as ARM, Kunpeng). Furthermore, these macros provide a unified interface for inserting barriers on demand when rewriting system calls.

[0048] Step 2: Rewrite the shared memory-related system calls and compile them into a dynamic library.

[0049] For Linux shared memory kernel system calls (shmget, shmat, shmdt, shmctl, etc.) invoked at the component layer, rewrite functions with the same names as the original functions (function name, input parameters, and return type are completely identical to the original function). The execution flow of the rewritten system call function is as follows: Figure 5As shown, inside the function, based on the type of shared memory operation, corresponding memory barrier instructions are added before and after the original system call as needed. Specifically, the address of the original system call function is first obtained so that the original system call can be executed subsequently. Then, read / write barrier instructions are added. After executing the original system call, read / write / full barrier instructions are added. Finally, the execution result is returned, and the hijacking ends.

[0050] In this embodiment, write barriers are always inserted before the original system call. Their function is to ensure that all write operations on shared memory parameters have been completed and are globally visible before entering kernel mode. Read barriers or full barriers are inserted after the original system call, depending on the impact of the system call on shared memory. For example, for shmget and shmat, which mainly involve obtaining the identifier or address of shared memory (a read operation), a read barrier is sufficient to ensure the visibility of the result. For shmdt, which unmaps the address of the current process from the shared memory segment (a write operation), a full barrier is required to ensure that the unmapping operation is completed for all processors. Other system calls, such as shmctl, can flexibly choose barriers based on their specific operation type.

[0051] Compile all rewritten system call functions into independent dynamic link libraries (such as shm_hook.so) to modularly encapsulate the memory barrier adaptation logic. The compilation command is: `gcc -fPIC -shared -o shm_hook.so shm_hook.c -ldl`. The code below is the modified version of the shmget system call function, adding read / write memory barrier instructions before and after the original system call to ensure the program's correctness in a multi-threaded environment.

[0052] / / Original shmget function pointer type definition typedef int (*orig_shmget_t)(key_t key, size_t size, int shmflg); / / Hijacking of the shmget function implementation int shmget(key_t key, size_t size, int shmflg) { / / Get the address of the original function static orig_shmget_t orig_shmget = NULL; if (!orig_shmget) { orig_shmget = (orig_shmget_t)dlsym(RTLD_NEXT, "shmget"); } / / Write barrier: Ensure parameters are prepared WRITE_BARRIER(); / / Call the original function int result = orig_shmget(key, size, shmflg); / / Read barrier: Ensures result visibility READ_BARRIER(); return result; } Step 3: Load the dynamic library through user-mode hijacking and start the business process.

[0053] This method employs the Linux LD_PRELOAD environment variable to hijack Linux user-space system calls. It's a lightweight hijacking solution that only affects currently running processes, posing no risk of kernel crashes and requiring no modification to the business process's binary executable. This is achieved through commands. LD_PRELOAD=. / shm_hook.so . / target_program When the original business process is started, the Linux dynamic linker will load the custom dynamic library first. When the component layer calls the Linux shared memory system call, it will be automatically redirected to the rewritten function with the same name, and the memory barrier instruction will be executed without the user's awareness. No code in the business layer and component layer needs to be modified at all.

[0054] After the above modifications, the information system exhibits the following characteristics during operation: Figure 4 The architecture shown depicts a system where the business layer and component layer code remain completely unchanged. All shared memory-related system calls are intercepted by the adaptation layer's dynamic library and memory barriers are inserted, ensuring correct operation on chips with weak memory models. This architecture completely isolates the memory barrier adaptation logic within the newly added adaptation layer. Business developers do not need to understand the barrier details, and testers can independently verify the adaptation layer's functionality. When porting to a new chip architecture is required, only the adaptation layer's dynamic library needs adjustment; the business layer and component layer require no modification, achieving a smooth evolution of the technology stack. Therefore, this application not only provides a non-intrusive transformation method but also constructs a corresponding information system with layered decoupling characteristics. This system can adapt to chip architectures with different memory models and possesses high maintainability and portability.

[0055] The technical scope of this application is not limited to the contents of the above specification. Those skilled in the art can make various modifications and variations to the above embodiments without departing from the technical concept of this application, and all such modifications and variations should fall within the scope of this application.

Claims

1. A non-invasive Linux memory barrier refactoring method for an information system ported from a first memory model chip architecture to a second memory model chip architecture, the first memory model chip architecture being a strong memory model chip architecture, the second memory model chip architecture being a weak memory model chip architecture, the strong memory model chip architecture including an x86 or x86-64 architecture, the weak memory model chip architecture including an ARM architecture, the information system including a business layer, a component layer and a system call layer, the component layer implementing inter-process communication through invoking a Linux shared memory system call in the system call layer, characterized in that, The non-intrusive Linux memory barrier modification method adds an adaptation layer between the component layer and the system call layer, and implants the memory barrier through the adaptation layer. Specifically, it includes: S1: In the adaptation layer, identify at least one target system call invoked by the component layer, where the target system call is part or all of the Linux shared memory system calls; S2: In the adaptation layer, for each target system call, a rewritten function with the same name as the target system call is constructed based on the operation semantics and data flow of that target system call; the execution logic inside the rewritten function includes, in sequence: Execute the first memory barrier instruction, the type of which is configured to ensure that the input parameter preparation operations and the preceding memory state before calling the target system call are globally visible to the system. Execute the original instruction that invoked the original target system call; Execute the second memory barrier instruction, the type of which is configured to ensure that the return result and shared memory status after the target system call is completed are immediately visible to subsequent business process operations. S3: Compile the rewritten functions in the adaptation layer into a dynamic link library; S4: When starting the business process of the information system, the dynamic link library of the adaptation layer is loaded preferentially by preloading environment variables. This causes the operating system's dynamic linker to prioritize the use of the rewritten function in the adaptation layer when parsing the component layer's call to the target system, thereby intercepting the component layer's call to the target system and redirecting the call to the rewritten function.

2. The non-invasive Linux memory barrier retrofit method of claim 1, wherein, The preloaded environment variable is the LD_PRELOAD environment variable, which is used to hijack Linux user-space system calls.

3. The non-invasive Linux memory barrier retrofit method of claim 1, wherein, The target system call is a Linux shared memory operation-related system call, including at least one of shmget, shmat, shmdt, and shmctl.

4. The non-invasive Linux memory barrier retrofit method of claim 3, wherein, The first memory barrier instruction is a write memory barrier instruction; the second memory barrier instruction is a read memory barrier instruction or a full memory barrier instruction; when the target system call is shmget or shmat, the second memory barrier instruction is a read memory barrier instruction; when the target system call is shmdt, the second memory barrier instruction is a full memory barrier instruction.

5. The non-invasive Linux memory barrier retrofit method of claim 1, wherein, Constructing the rewritten function also includes: obtaining the original function address of the target system call using the dlsym function and the RTLD_NEXT handle; the steps of compiling into a dynamic link library include using the gcc compiler with the -fPIC and -shared options, and linking the dl library.

6. The non-invasive Linux memory barrier retrofit method of claim 1, wherein, Memory barrier instructions are implemented through the atomic_thread_fence function and defined as the following macros: the function parameter for a read memory barrier is memory_order_acquire, the function parameter for a write memory barrier is memory_order_release, and the function parameter for a full memory barrier is memory_order_seq_cst.

7. An information system, characterized in that, The method described in any one of claims 1 to 6 is used to modify the Linux memory barrier, including: The business layer contains multiple business processes used to implement business logic; The component layer, located below the business layer, provides a custom shared memory container for the business layer to perform inter-process communication, and implements the operation of the custom shared memory container by calling the Linux shared memory system calls in the system call layer. The system call layer provides the underlying Linux shared memory system call interface; The adaptation layer, located between the component layer and the system call layer, includes a dynamic link library containing a rewrite function that rewrites at least one target system call. The rewrite function has the same name as the original system call, and a first memory barrier instruction and a second memory barrier instruction are inserted before and after the original system call function is called, respectively. When the business process starts, the dynamic link library of the adaptation layer is loaded first by preloading environment variables, so that the component layer's calls to the target system are automatically intercepted by the operating system's dynamic linker and redirected to the rewritten function of the adaptation layer.

Images