Zero-delay hot repair method during software running

Abstract

The invention discloses a zero-hysteresis hot repair method during software operation, the repair method is a HotFix system, and the HotFix system comprises an address analysis stage, a process state monitoring stage and a new and old migration stage. Compared with the prior art, the method has the advantages that the safe area and the non-safe area of the program code can be automatically divided, the process state is efficiently monitored, updating of the process state and distribution of the control flow are completed, and safe migration from old codes to new codes in the multi-thread program is achieved.

Description

Technical Field

[0001] The present invention relates to the technical field of repair methods, and specifically to a zero-latency hot-fix method during software operation. Background Art

[0002] At present, most applications of hot-fix adopt the Activeness Safety (AS) method, that is, only when the executable code segment is not in an active state can the target software be hot-fixed, which will inevitably affect the immediate effect of the update. In addition, in order to accurately obtain the safe point, many methods also need to modify the kernel, compiler or even the source code, which directly affects their application scope.

[0003] Traditional methods repair software defects in the way of "stop-fix-restart". However, in some scenarios, such as cloud environment, the cost of restarting key software is high. Dynamic repair can achieve defect repair during software operation, thus avoiding software restart. However, dynamic repair needs to accurately identify the safe state of the running software (process), otherwise it will cause execution exceptions or even process crashes. To cope with the complex state problems in a multi-threaded environment, most existing methods need to coordinate and wait between functional modules to enter the safe state, and the parallelism of the repair process is insufficient, resulting in low repair efficiency, scope and success rate. Summary of the Invention

[0004] The technical problem to be solved by the present invention is to overcome the above technical defects;

[0005] To solve the above problems, the technical solution of the present invention is: a zero-latency hot-fix method during software operation, and the repair method is a HotFix system, which includes an address analysis stage, a process state monitoring stage, and a repair code migration stage;

[0006] The address analysis stage includes patch difference extraction and analysis of the function call graph. The purpose of the patch difference extraction component is to compile the original source code without patching and the updated source code after patching to generate corresponding assembly files. By comparing these two assembly files, a detailed patch difference file is generated. The analysis of the function call graph determines the security of the function by analyzing the call relationship and function attributes. In this way, the system can identify the safe area in the program, that is, the area where safe operations can be performed during the repair process without worrying about causing execution conflicts, so as to establish a jump table, a dangerous function table, and a safe address table;

[0007] The process status monitoring phase includes monitoring probes and multi-thread status monitoring. The monitoring probes determine the change points of the function installation status in real time through the signals captured by the probes, so as to monitor the process security status. After confirming that the thread is in a safe state, the monitoring probes trigger repair actions, so as to migrate the control flow in the un-repaired code of the thread to the repaired code. When there are dependencies between threads, a bitmap is introduced to manage the status of the threads. The length of the bitmap corresponds to the number of threads with dependencies, and each bit represents the security status of a thread;

[0008] The migration phase includes dynamic allocation of redundant memory and runtime redirection. The dynamic allocation of redundant memory will obtain the pc pointer when the process is interrupted or swapped out, and use int80 to overwrite the code it points to, so as to embed the mmap system call into the program's interrupt context when an interruption occurs, thus realizing the dynamic allocation of memory space. After obtaining the appropriate timing of hot repair through status monitoring, the runtime redirection cancels the security probes and updates the status of the current process, so as to distribute the control flow.

[0009] Furthermore, the jump table records the address differences between the old and new functions, providing navigation for jumps during the hot repair process. The dangerous function table is used to mark the addresses of functions that cause problems, so as to handle dangerous functions during the hot repair process. The safe address table is used to list all safe repair points in the program, ensuring that repair operations performed at these locations will not introduce new errors or cause the program to crash.

[0010] Furthermore, the address analysis phase generates a detailed patch difference file, which contains all necessary modification information. HotFix performs secondary compilation on the assembly file to create a temporary relocation file, which contains all information about the patch differences.

[0011] The advantages of the present invention compared with the existing technologies are as follows:

[0012] The present invention uses a maintenance safety table, a danger table and a jump table to record function addresses, and inserts probes into the process according to the addresses in the tables, so as to realize differential processing of functions with different attributes. It converts the work of scanning the function stack into obtaining the information returned by the probes, which reduces the workload of manually marking jump points and greatly improves the automation of dynamic software repair. Depending on the function call directed graph, in the process of repairing a multi-threaded running program, a method of migrating single threads one by one from safe points is adopted. This method determines the security status of functions with call relationships in a single thread by establishing a bitmap, discovers the security status through monitoring the thread status, and completes the distribution of the control flow in the safe state, that is, jumps the thread in a single running state from the old code to the repaired code while ensuring the uninterrupted operation of other threads. Brief Description of the Drawings

[0013] Figure 1 It is the system architecture diagram of a zero-latency hotfix method during software runtime according to the present invention.

[0014] Figure 2 It is the function call relationship diagram of a zero-latency hotfix method during software runtime according to the present invention.

[0015] Figure 3 It is the graph coloring example diagram of a zero-latency hotfix method during software runtime according to the present invention.

[0016] Figure 4 It is the probe example architecture diagram of a zero-latency hotfix method during software runtime according to the present invention. Detailed Description of the Preferred Embodiment

[0017] The following further describes the detailed implementation manners of the present invention with reference to the drawings, where the same components are denoted by the same reference numerals.

[0018] It should be noted that the terms "front", "rear", "left", "right", "upper" and "lower" used in the following description refer to the directions in the drawings, and the terms "inner" and "outer" respectively refer to the directions towards or away from the geometric center of a specific component.

[0019] To make the content of the present invention more clearly understood, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention.

[0020] As Figures 1 to 4 shown, a zero-latency hotfix method during software runtime, the hotfix method is a HotFix system, and the system includes an address analysis stage, a process status monitoring stage, and a repair code migration stage;

[0021] The address analysis stage includes patch difference extraction and function call graph analysis. The purpose of the patch difference extraction component is to compile the unpatched original source code and the updated patched source code to generate corresponding assembly files. By comparing these two assembly files, a detailed patch difference file is generated. The function call graph analysis determines the security of functions by analyzing the call relationships and function attributes. In this way, the system can identify the safe areas in the program, that is, the areas where safe operations can be performed during the repair process, and the dangerous areas, that is, the areas where execution conflicts may occur, so as to establish a jump table, a dangerous function table, and a safe address table;

[0022] The process status monitoring stage includes probe monitoring and multi-thread status monitoring. The monitoring probe determines the change points of the function security status in real time through the signals of the probe, so as to monitor the process security status. After the multi-thread status monitoring confirms that the thread is in a safe state, it triggers a code repair action using the monitoring probe, migrates the control flow in the un-repaired code in the thread to the repaired code. When there are dependencies between threads, a bitmap is introduced to manage the status of the threads. The length of this bitmap corresponds to the number of threads with dependencies, and each bit represents the security status of a thread;

[0023] The repaired code migration stage includes dynamic allocation of redundant memory and control flow redirection during runtime. The dynamic allocation of redundant memory obtains the pc pointer when the process is interrupted or swapped out, and uses int80 to overwrite the code it points to, so as to embed the mmap system call into the interrupt context of the program when an interrupt occurs, thereby realizing the dynamic allocation of memory space. After obtaining the timing of hot repair by monitoring the running status of the status thread, the runtime redirection cancels the security probe and updates the status of the current process, so as to perform the distribution of the control flow;

[0024] The jump table records the address differences between the old and new functions, providing navigation for jumps during the hot repair process. The dangerous function table marks the function addresses that cause problems, so as to perform special processing during the hot repair process. The specific steps of the function address are as follows: The address jumped by the callq instruction is the entry of the called function. The nodes of the directed graph G represent functions. The entry function main() is the starting point of G. The edges of G point from the calling function to the called function. The directed edges record both the jump address and the return address of the function call. The safe address table lists all the safe repair points in the program, ensuring that the repair operations performed at these positions will not introduce new errors or cause the program to crash;

[0025] Regarding the status of the uncolored nodes in graph G, the rules followed by the safe point coloring algorithm are as follows:

[0026] (1) The entry node main() is set to green;

[0027] (2) If a certain node needs to be repaired, it is red;

[0028] (3) If all the parent nodes of a certain node are dangerous, it is red;

[0029] (4) If all the parent nodes of a certain node are safe, it is green;

[0030] If the parent nodes of a certain node are not all safe, it is yellow;

[0031] Taking the main() function as the entry node, all function nodes in the program can be colored in the offline case. Determining the function security state is to find the timing of control flow migration during hotfix, that is, when the process control flow jumps to a new address. Since the jump information is recorded on the directed edge, the directed edge also needs to determine the security state, and its value is the same as the node_state value of the starting node;

[0032] The main() function is initialized to green. After preprocessing, it is found that functions E() and F() need to be modified, so they are initialized to red. The security states of each function in the directed graph G. Among them, the only parent node of function G() is function E(), so it is red. The parent node D() of function I() is in a safe state, and the parent node F() is in a dangerous state, so it is yellow. The parent node I() of function H() is not safe, so it is yellow;

[0033] The security probe is used to change the state to safe. SPHOTFIX inserts the first security probe at the address of the instruction before the callq instruction, and the role of this security probe is to update the process state. When a certain process is about to execute the function to be repaired, the process will be initialized as a dangerous process. When a safe edge is found through static analysis, the starting point of the safe edge and the previous function can be determined to be in a safe state. When the process executes to the first security probe, the state changes from dangerous to safe, which means that it can be determined at this time that the process meets the hotfix condition. SPHOTFIX inserts the second security probe at the address of the instruction after the callq instruction. When the process executes to this probe, it means that the dangerous function has been executed, and the process state returns to the safe area. Therefore, the process meets the hotfix condition from this time on.

[0034] The address analysis stage generates a detailed patch difference file, which contains the differential information between the old and new codes. Then, HotFix performs secondary compilation on the assembly file to create a temporary relocation file, which contains all the information in the patch difference file.

[0035] In specific use, in the offline stage, first add two parameters, -ffunction-sections and -fdata-sections, before software compilation, which can create each function and symbol as a section to locate the differences in the program code. Then, compile the original program and the program after updating the patch respectively, input the compiled binary executable files into the symbol table, and record the old and new executable files involved in code modification.

[0036] In addition, HotFix parses the program executable file, establishes a function call directed graph according to the proposed function safety status determination strategy and combines with the graph theory search technology to extract the function jump information and return information at the safe and dangerous boundaries of the program. Finally, HotFix generates three record tables that determine thread jumps.

[0037] In the online stage, HotFix realizes code repair during program operation. HotFix first starts the program and records the program's pid, then completes the secondary loading of the patch. During the repair process, unloaded functions will be redirected, and probes will be inserted into the target functions in the source address space. After determining the safety status, code repair and control flow migration operations are performed. Finally, the original defective code is replaced with the repaired code during code operation.

[0038] The above describes the present invention and its implementation manners. Such description is not restrictive. What is shown in the drawings is only one of the implementation manners of the present invention. The actual structure is not limited thereto. Generally speaking, if those of ordinary skill in the art are inspired by it and design similar structural manners and embodiments without creative efforts without departing from the gist of the present invention, they shall fall within the protection scope of the present invention.

Claims

1. A zero-latency hotfix method during software runtime, characterized in that: The repair method is the HotFix system, which includes an address analysis stage, a process status monitoring stage, and a repair code migration stage; The address analysis stage includes patch difference extraction and analysis of the function call graph. The purpose of the patch difference extraction component is to compile the unpatched original source code and the updated patched source code to generate corresponding assembly files. By comparing these two assembly files, a detailed patch difference file is generated. The analysis of the function call graph determines the security of functions by analyzing the call relationships and function attributes. In this way, the system can identify the safe areas in the program, that is, the areas where safe operations can be performed during the repair process without worrying about causing execution conflicts, so as to establish a jump table, a dangerous function table, and a safe address table; The process status monitoring stage includes monitoring probes and multi-threaded status monitoring. The monitoring probes determine the change points of the function installation status in real time through the signals captured by the probes, so as to monitor the security status of the process. After confirming that the thread is in a safe state, the monitoring probes are used to trigger the repair action, so as to migrate the control flow in the unpatched code of the thread to the repaired code. When there are dependencies between threads, a bitmap is introduced to manage the status of the threads. The length of the bitmap corresponds to the number of dependent threads, and each bit represents the security status of a thread; The migration stage includes dynamic allocation of redundant memory and runtime redirection. The dynamic allocation of redundant memory obtains the pc pointer when the process is interrupted or swapped out, and uses int80 to overwrite the code it points to, so as to embed the mmap system call into the interrupt context of the program when an interrupt occurs, thus realizing the dynamic allocation of memory space. After obtaining the appropriate timing of the hot fix through status monitoring, the runtime redirection cancels the security probes and updates the status of the current process, so as to distribute the control flow.

2. The zero-latency hotfix method during software operation according to claim 1, characterized in that: The jump table records the address differences between the old and new functions, providing navigation for jumps during the hot fix process. The dangerous function table is used to mark the function addresses that cause problems, so as to handle dangerous functions during the hot fix process. The safe address table is used to list all safe repair points in the program, ensuring that repair operations performed at these locations will not introduce new errors or cause the program to crash.

3. A zero-latency hotfix method during software runtime according to claim 1, characterized in that: The address analysis stage generates a detailed patch difference file, which contains all the necessary modification information. HotFix performs a secondary compilation on the assembly file to create a temporary relocation file, which contains all the information of the patch difference.

4. A zero-latency hotfix method during software runtime according to claim 1, characterized in that: The process status monitoring stage includes monitoring probes and multi-threaded status monitoring. The monitoring probes determine the change points of the function installation status in real time through the signals captured by the probes.

Images