A non-restart code repair method using memory gaps

Abstract

The application discloses a non-restart code repair method using memory gaps, comprising the following steps: screening target objects of repair codes; searching memory layout, managing and storing information of retrieved memory gaps, and matching space information corresponding to the repair codes; generating a code repair scheme by comparing modification requirements of functions in the repair codes, replacing modified function pointers or parameter structures of the functions; updating information of a kernel symbol table; writing data and data structures required to be repaired by the target objects into the memory gaps, generating a kernel module according to the code repair scheme, and realizing code repair of a non-restart system by loading the kernel module and using a HOOK mechanism. The application is suitable for different types of code repair patches in real environments and has good universality.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method for repairing code without restarting by utilizing memory gaps. Background Technology

[0002] Modern software and systems contain numerous vulnerabilities, requiring code patching for repair. Patching effectively fixes vulnerabilities or improves code functionality, enhancing the security, robustness, and integrity of software and systems. It is a crucial component of modern computing systems and an important aspect of their maintenance. However, traditional code patching methods typically require restarting the software or device, causing service interruptions and potential losses. Some service providers, to ensure service stability, prefer to skip updates or abandon patching altogether, leaving vulnerabilities in the system unpatched for years, posing security risks. Attackers can exploit these unpatched vulnerabilities to steal sensitive user information, threatening user privacy and security. Therefore, there is an urgent need to design reliable, restart-free code patching methods to address the issue of code patching requiring software or device restarts.

[0003] Hot patching is a widely used code repair technology. References [1] SINIAVINE M, GOELA. Seamless kernel updates [C] / / 2013 43rd Annual IEEE / IFIP International Conference on Dependable Systems and Networks (DSN). IEEE, 2013: 1-12., [2] C.Islam, V.Prokhorenko, and MABabar, “Runtime software patching: Taxonomy, survey and future directions,” Journal of Systems and Software, vol. 200, p. 111652, 2023., [3] ZHOU L, ZHANG F, LIAO J, et al. KShot: Live Kernel Patching with SMM and SGX [C] / / 2020 50th Annual IEEE / IFIP International Conference on Dependable Systems and Networks (DSN). IEEE, 2020: 1-13., [4] POIMBOEUF J, JENNINGSS. Introducing kpatch: Dynamic kernel patching[J]. Red Hat Enterprise Linux Blog, 2014, 26. These papers employ virtualization, data replacement mechanisms, binary instrumentation, and direct memory write techniques for code repair. The aforementioned literature provides in-depth research on target data structure replacement, replacement strategy selection, and subsequent code integrity and correctness verification.

[0004] The research in references [1]-[4] and [5] I. Mugarza and JCMugarza, “Cetratus: Live updates in programmable logic controllers,” in IEEE International Workshop of Electronics, Control, Measurement, Signals and their application to Mechatronics, pp.1–7, IEEE, 2021. When performing code repair, since the program and device cannot be restarted, it is necessary to obtain extended space in the memory space of the original program and ensure its association with the original data. Since it is impossible to introduce a new memory layout by recompiling, the newly added or adjusted data structure in the patch cannot be properly placed in memory. In general, the patch repair scheme will add a jump instruction to the memory of the original data structure. When it is necessary to access the updated data structure and data unit, the control flow is transferred to a centralized management unit responsible for control flow jump through the jump instruction. The center completes the jump matching, thereby realizing the access to the repaired data in memory. This method can, to a certain extent, modify the data structure, function call, and code instruction in memory. However, this code-fixing method requires allocating a new memory space and setting up a central management unit responsible for control flow transfer. This centralized management unit, on the one hand, needs to match and verify the source and destination addresses requesting control flow transfer, introducing significant system overhead; on the other hand, it disrupts the internal relationships of data structures, causing a decrease in memory access speed after code fixes. Simultaneously, some memory units accessed directly using address offsets become inaccessible, violating the semantics of the original code.

[0005] Therefore, existing technologies cannot meet the requirements of repairing code without restarting or introducing excessive runtime overhead. There is an urgent need to design a repair method suitable for code repair without restarting and for fast access to memory data. This method should consider the memory space layout characteristics during code repair and improve runtime efficiency after the code is repaired. Summary of the Invention

[0006] The purpose of this invention is to provide a non-reboot code repair method that utilizes memory gaps to achieve seamless repair and updates of code with security vulnerabilities, thereby improving system security and stability. It also optimizes system performance to ensure the continuity and reliability of computing services.

[0007] The technical solution of this invention is: a method for repairing code without restarting by utilizing memory gaps, comprising the following steps:

[0008] Step 1: Filter the target objects for the code repair;

[0009] Step 2: Search the memory layout, manage and store the information of the retrieved memory gaps, and match the space information corresponding to the repair code;

[0010] Step 3: By comparing the modification requirements for functions in the repair code, replace the function pointers or function parameter structures that need to be modified, and generate a code repair solution;

[0011] Step 4: Update the kernel symbol table information;

[0012] Step 5: Write the data and data structure of the target object that need to be repaired into the memory gap, generate a kernel module according to the code repair plan, and use the HOOK mechanism to achieve code repair without restarting the system by loading the kernel module.

[0013] Preferably, the process of filtering and repairing the code includes the following steps:

[0014] Step 1.1: Determine whether the object of the repair code is a replacement class repair object;

[0015] If so, then perform object replacement to complete the code repair;

[0016] If not, proceed to step 1.2;

[0017] Step 1.2: Determine whether the object being repaired matches the object type being repaired;

[0018] If yes, proceed to step 2; if no, restart the system.

[0019] Preferably, step 2 further includes determining the size of the memory gap and the address offset of the memory gap through the memory address offset of the data member, and storing them in a hash table;

[0020] The size of the memory gap is calculated using the following formula:

[0021] gap_capacity=next_location-size-member_location

[0022] The address offset of the memory gap is calculated using the following formula:

[0023] gap_location=next_location-gap_capacity

[0024] Where gap_capacity is the size of the memory gap where the repair code is stored, next_location is the memory address offset of the next data member, size is the actual memory size occupied by the current data, and member_location is the memory address offset of the data member.

[0025] Preferably, the memory gap space includes native gaps and splicing gaps.

[0026] Preferably, in step 3, the modification of the function in the repair code scheme specifically includes:

[0027] If the function prototype does not change during the function call, the function pointer is replaced in the repair plan to replace the called function object, so that the replaced function pointer can be called after the repair is completed.

[0028] If the function prototype changes during a function call, the parameter passing rules are modified first, and then the function pointer is replaced so that the replaced function pointer can be called and the modified call parameters can be used after the repair is completed.

[0029] Preferably, step 3 also includes modifying the kernel compilation configuration file to enable the SYSFS virtual file system, dynamic module loading, DYNAMIC_FTRACE_WITH_REGS feature, and HAVE_RELIABLE_STACKRACE trusted stack feature.

[0030] Preferably, the replacement of the function pointer specifically involves: using the kallsyms_lookup_name() function to link the memory functions involved in the repair process, determining the distribution and memory offset of the memory functions in memory, and replacing the memory functions with the repaired function pointers.

[0031] Preferably, the use of the HOOK mechanism specifically means that the running thread still accesses the original data and the original data structure; when the previous thread ends and a new thread starts, the thread then accesses the data and data structure in the memory gap.

[0032] Compared with the prior art, the beneficial effects of the present invention are:

[0033] (1) By utilizing the tiny gaps between memory objects during program execution to load the new data and data structures after code repair, it is possible to change the operation of the system and repair the fragile code without recompiling and restarting the system and services, which has high practicality.

[0034] (2) By repairing the code in the existing memory layout, no additional memory space is needed. The repaired data can be accessed in the native address offset way. Since the memory gap itself is close to the original data location, according to the principle of locality of program, it does not interfere with the work of CPU cache. The impact on the access efficiency of the data after code repair is negligible, with high running efficiency and low system overhead.

[0035] (3) By utilizing the module's generation and loading functions, and with new and old data existing in memory simultaneously, a stable switching method is provided for multi-threaded memory management, ensuring data consistency.

[0036] (4) This invention is applicable to different types of code repair patches in real environments and has good universality. Attached Figure Description

[0037] Figure 1 This is a schematic diagram of the process of the present invention;

[0038] Figure 2 A comparison chart of function execution times to measure the execution overhead of embodiments of the present invention;

[0039] Figure 3 A statistical chart showing the number of memory data structures and the number of structures with gaps to measure the usability of embodiments of the present invention;

[0040] Figure 4 A statistical chart showing the number and capacity of memory gaps in different data structures used to measure the usability of embodiments of the present invention. Detailed Implementation

[0041] The technical solution of the present invention will be described in detail below, but the scope of protection of the present invention is not limited to the embodiments described. To make the content of the present invention more apparent and understandable, further description will be given below in conjunction with the accompanying drawings and specific embodiments.

[0042] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0043] like Figure 1 As shown, this invention discloses a method for repairing code without restarting by utilizing memory gaps, comprising the following steps:

[0044] Step 1: Filter the target objects for the code repair;

[0045] Based on the official patch documentation, the target objects for the code fixes are selected, and the specific steps are as follows:

[0046] Step 1.1: Determine whether the target object of the repair code is the target object of the replacement class;

[0047] If so, then object replacement is performed to complete the code repair; the replacement target object includes the following types:

[0048] A. Description class: Objects that modify documents, descriptions, and introductions;

[0049] B. Configuration class: An object for modifying code option configuration files and configuration option entries;

[0050] C. Value Change Class: Objects that change the value of a specific variable without changing the data storage type.

[0051] If not, proceed to step 1.2;

[0052] Step 1.2: Determine whether the target object of the repair code matches the type of object to be repaired;

[0053] If yes, proceed to step 2;

[0054] If not, restart the system; the target objects include the following types:

[0055] A. Assembly objects in the boot phase annotated with the macro `init`;

[0056] B. Objects involving kernel feature changes to ftrace, kprobe, and tracepoint.

[0057] Step 2: Search the memory layout, manage and store the information of the retrieved memory gaps, and match the space information corresponding to the repair code;

[0058] Query the .debuginfo section information and obtain the member_location through the DWARF description of core_dump.

[0059] Then we have:

[0060] gap_capacity=next_location-size-member_location

[0061] Where gap_capacity is the size of the memory gap where the repair code is stored, next_location is the memory address offset of the next data member, size is the actual memory size occupied by the current data, and member_location is the address offset of the data member in the memory layout.

[0062] The address offset of the gap is:

[0063] gap_location=next_location-gap_capacity

[0064] The addresses and size information of all found memory gaps are stored in a hash table for subsequent management and access of memory gaps.

[0065] For some small memory gaps, read macros and write macros are defined, and memory gaps at different locations are combined into a usable size based on combined pointers, which are also stored in a hash table.

[0066] A flag is set to indicate whether the memory gap is a spliced ​​gap or a native gap.

[0067] The core of the code macro that writes the pointer ptr to memory Memory_Address is:

[0068]

[0069] The core of the code macro that reads specific content from the ptr pointer (memory address) is:

[0070] ((((EXTENDLEN)(ptr->top))<<0x20)+(EXTENDLEN)(ptr->bottom))

[0071] Step 3: By comparing the modification requirements for functions in the repair code, replace the function pointers or function parameter structures that need to be modified, and generate a code repair solution;

[0072] The analysis and comparison of the function modification requirements in the code repair solutions specifically include:

[0073] ① If the modified data type is not used in the function call, that is, the data structure has not changed, only the function object being called has changed, and the function prototype is still valid, then the function pointer is replaced in the repair plan so that the replaced function pointer can be called after the repair is completed, thus achieving code repair;

[0074] ② If the number of parameters in a function call is modified, i.e. the function prototype is changed, the parameter passing rules are modified first, and then the function pointer is replaced. After the repair is completed, the replaced function pointer is called and the modified call parameters are used to achieve code repair.

[0075] Since function call parameters are only passed on the stack, and the compiled binary code does not need to be verified, replacing or modifying the function pointer is equivalent to modifying the function call.

[0076] Modify the .config configuration file to enable the SYSFS virtual file system, dynamic module loading, DYNAMIC_FTRACE_WITH_REGS feature, and HAVE_RELIABLE_STACKTRACE trusted stack feature.

[0077] The kallsyms_lookup_name() function is used to link the memory functions involved in the repair process, determine the distribution and memory offset of the memory functions in memory, and replace the memory functions with modified function pointers to achieve code repair.

[0078] Step 4: Update the kernel symbol table information;

[0079] The kernel symbol table is updated by using vmlinux's System.map to query the kernel symbol table file, saving the queried loaded symbols and their memory layout. After the code repair is completed, the symbol table information is updated and managed.

[0080] Step 5: Write the data and data structure of the target object that need to be repaired into the memory gap, generate the corresponding module according to the code repair plan, and use the HOOK mechanism to achieve code repair without restarting the system by loading the module.

[0081] The process replaces the data and data structures that need repair in the memory region. Global variables reside in the .data segment, while local variables reside in the memory heap. The data and data structures of the target object that need repair are written into the memory gap where the matching region exists. At this time, the original data region is unaffected, and the original data and data structures remain unchanged. The memory modification generates a corresponding kernel module, which is loaded using the insmod instruction. At this point, the hook takes effect and takes over memory access in the specific region. Running threads still access the original data and data structures. When the previous thread ends and a new thread starts, the modified memory, i.e., the data and data structures in the memory gap, is used. The code repair is completed without recompiling or restarting the code.

[0082] The effectiveness, execution efficiency, and usability of the embodiments of the present invention will be verified through the following examples.

[0083] Example 1: Verification of the effectiveness of the embodiments of the present invention:

[0084] Eight different types of code vulnerabilities were downloaded from the Common Vulnerabilities & Exposures (CVE) database. The descriptions of the vulnerabilities are shown in Table 1. The patch code was installed, and debug mode was enabled in the emulator to track whether the patch code was effective.

[0085] The modification of the memory gap vulnerability repair code first involves determining the type of vulnerability modification. The code repairs in Table 1 all involve the modification and replacement of data and data structures. The repair process includes file modification, data structure modification, and data insertion. Then, by viewing the .debuginfo information using gdb, the addresses and sizes of available memory gaps in the memory layout are located. Gaps with insufficient space are concatenated using combined pointers, and the corresponding information is stored in a hash table. Next, function calls are modified, the .config configuration file is modified, enabling the SYSFS virtual file system, dynamic module loading, DYNAMIC_FTRACE_WITH_REGS feature, and HAVE_RELIABLE_STACKTRACE trusted stack feature, replacing function pointers, and generating a code repair solution. Then, the hash table is searched for memory gaps that meet the code repair requirements. The data and data structures that need to be repaired are written into the memory gaps, and a kernel module is generated for the corresponding repair. The insmod instruction is used to load the kernel module, and a hook mechanism is used to achieve the repair of the code defect without restarting. Finally, the effectiveness of the invention is verified by checking whether the code vulnerability still exists and whether it can be repaired after this method.

[0086] Table 1. Verification Results of Real Vulnerability Remediation

[0087]

[0088] Example 2: Execution cost metric

[0089] To measure the overhead introduced by the code fixes in this invention, an rdtsc instruction was inserted during kernel module generation to read the CPU timestamp. The clock cycles C0 obtained from the rdtsc instruction executed before the target function's execution, and the clock cycles C1 obtained from the rdtsc instruction executed after the target function's execution, are used to calculate the time T between them, as follows:

[0090]

[0091] Where f represents frequency.

[0092] The execution time of the six functions involved in the repair process was monitored. After 10 experiments and the average value was taken, the results before and after the repair were compared, as shown in Table 2. It can be seen that, compared with other code repair methods, the function call overhead of this invention is similar to that of the repair method of recompiling and restarting the service, and the execution efficiency is better than other code repair methods.

[0093] Example 3: Availability Measurement of the Solution

[0094] To verify that the embodiments of the present invention are applicable to different code and kernel versions, different kernel versions were searched to check whether there were sufficient memory gaps and capacity to accommodate the instructions required for code repair. The number of data structures in different kernel versions and the number of data structures satisfying the present invention were statistically analyzed, and the results are as follows: Figure 3 As shown.

[0095] Statistical analysis revealed that approximately 20% of the data structures in the kernel contain memory gaps that can be utilized by this invention. Analysis of memory gaps and their capacities in common data structures showed that, on average, each data structure contains about 10 usable memory gaps for loading code repair instructions and memory rewriting, with each gap averaging approximately 55.6 bytes. Therefore, this invention can find a sufficient number and size of memory gaps in regular code to accommodate repair code.

[0096] All parts not covered in this invention are the same as or can be implemented using existing technologies.

[0097] As described above, although the invention has been shown and described with reference to specific preferred embodiments, it should not be construed as limiting the invention itself. Various changes in form and detail may be made without departing from the spirit and scope of the invention as defined in the appended claims.

Claims

1. A method for repairing code without restarting by utilizing memory gaps, characterized in that: Includes the following steps: Step 1: Filter the target objects for the code repair; Step 2: Search the memory layout, obtain the memory address offset of the data structure members by analyzing the debugging information of the target program, calculate the memory gaps between the data structure members, manage and store the information of the retrieved memory gaps, and match the space information corresponding to the repair code. Step 2 also includes determining the size of the memory gap and the address offset of the memory gap by using the memory address offset of the data member, and storing them in a hash table; The size of the memory gap is calculated using the following formula: The address offset of the memory gap is calculated using the following formula: in, The size of the memory gap for storing the fix code. The memory address offset for the next data member. This represents the actual memory size currently occupied by the data. The memory address offset of the data member; Step 3: By comparing the modification requirements for functions in the repair code, replace the function pointers or function parameter structures that need to be modified, and generate a code repair solution; In step 3, the modifications to the functions in the repair code solution specifically include: If the function prototype does not change during the function call, the function pointer is replaced in the repair plan to replace the called function object, so that the replaced function pointer can be called after the repair is completed. If the function prototype changes during a function call, the parameter passing rules are modified first, and then the function pointer is replaced so that the replaced function pointer can be called and the modified call parameters can be used after the repair is completed. It also includes modifying the kernel build configuration file to enable the SYSFS virtual file system, dynamic module loading, DYNAMIC_FTRACE_WITH_REGS feature, and HAVE_RELIABLE_STACKRACE trusted stack feature; Step 4: Update the kernel symbol table information; Step 5: Write the data and data structure of the target object that need to be repaired into the memory gap, generate a kernel module according to the code repair plan, and use the HOOK mechanism to achieve code repair without restarting the system by loading the kernel module.

2. The method for repairing code without restarting by utilizing memory gaps according to claim 1, characterized in that: The process of filtering and repairing code objects includes the following steps: Step 1.1: Determine whether the target object of the repair code is the target object of the replacement class; If so, then perform object replacement to complete the code repair; If not, proceed to step 1.2; Step 1.2: Determine whether the target object of the repair code matches the type of object to be repaired; If yes, proceed to step 2; if no, restart the system.

3. The method for repairing code without restarting by utilizing memory gaps according to claim 1, characterized in that: The memory gap space includes native gaps and splicing gaps.

4. The method for repairing code without restarting by utilizing memory gaps according to claim 1, characterized in that: The replacement of the function pointer specifically involves: using the kallsyms_lookup_name() function to link the memory functions involved in the repair process, determining the distribution and memory offset of the memory functions in memory, and replacing the memory functions with the repaired function pointers.

5. The method for repairing code without restarting by utilizing memory gaps according to claim 1, characterized in that: The use of the hook mechanism specifically means that the running thread still accesses the original data and the original data structure; when the previous thread ends and a new thread starts, the thread then accesses the data and data structure in the memory gap.

Images