Patch function loading method and device and storage medium

Abstract

The invention relates to a patch function loading method and device and a storage medium, and the patch function loading method comprises the steps that a patch function is compiled to generate a dynamic link library; searching a first thread local storage TLS variable of the patch function from a dynamic link library; the first TLS variable is a TLS variable in a first access mode, and the first access mode is a relocation-dependent access mode; switching the searched first TLS variable from the first access mode to a second access mode, and generating a second TLS variable; the second access mode is an access mode for cancelling relocation dependence; and based on the dynamic link library, skipping to execute the patch function, and calling the second TLS variable. Through the method and the device, the problem that the dependence of the TLS variable on relocation is difficult to effectively reduce in a hot patch loading mode using the TLS variable is solved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a method, device and storage medium for loading a patch function. Background Art

[0002] With the development of computer technology and the increase of software functions, software defects are inevitable. In some scenarios with high requirements for software reliability, it is required that the device cannot be restarted and the business functions are not interrupted. In response to this requirement, hot patching technology is generally used to achieve the premise that the device does not restart. During the process running, the instructions of the defective function are replaced by instructions of the defective function to repair the defective function, so as to repair the defective function. The defective function refers to the function with erroneous logic running in the process. The defective function is also called the patch function, which refers to the function that repairs the erroneous logic and realizes the normal function.

[0003] During the patch loading process, thread safety is usually ensured through Thread Local Storage (TLS), which is a thread-level storage mechanism. However, there are multiple access modes for TLS variables, and the addressing methods of different access modes are different. For example, the Local Executable (LE) mode does not require relocation, while the General Dynamic (GD) mode addressing relies on the module ID and TLS block offset used for relocation, so the TLS variables in the GD mode cannot be relocated and addressed in the LE mode, resulting in serious relocation dependency for patch loading.

[0004] Currently, in the related technology, it is difficult to effectively reduce the dependence of TLS variables on relocation in the hot patch loading method using TLS variables, and no effective solution has been proposed yet. Summary of the invention

[0005] The embodiments of the present application provide a method, device and storage medium for loading a patch function, so as to at least solve the problem in the related art that it is difficult to effectively reduce the dependence of TLS variables on relocation in a hot patch loading method using TLS variables.

[0006] In a first aspect, an embodiment of the present application provides a method for loading a patch function, the method comprising: Compile the patch function to generate a dynamic link library; Searching the first thread local storage TLS variable of the patch function from the dynamic link library; the first TLS variable is a TLS variable in a first access mode, and the first access mode is an access mode of relocation dependency; Switching the searched first TLS variable from the first access mode to a second access mode to generate a second TLS variable; the second access mode is an access mode that cancels the relocation dependency; Based on the dynamic link library, the patch function is jumped and executed, and the second TLS variable is called.

[0007] In some embodiments, searching the first thread local storage TLS variable of the patch function from the dynamic link library includes: Obtaining, from the dynamic link library, a variable name of a TLS variable to be detected of the patch function; Based on the variable name of the TLS variable to be detected, whether there is matching relocation information is found from the relocation list stored in the dynamic link library; when the matching relocation information is found, it is determined that the TLS variable to be detected is the first TLS variable.

[0008] In some embodiments, switching the searched first TLS variable from the first access mode to the second access mode to generate a second TLS variable includes: Obtaining an executable file of a target process; the target process is a process of an application program that loads the patch function at runtime; Searching for a variable with the same name as the first TLS variable from the executable file, and determining a TLS variable offset of the first TLS variable in the thread local storage space based on the variable with the same name; According to the TLS variable offset, obtaining a target assembly code accessed based on the second access mode; Based on the assembly code position of the first TLS variable, the first TLS variable is replaced with the target assembly code, and the second TLS variable is generated.

[0009] In some embodiments, obtaining the variable name of the first TLS variable and the assembly code location of the first TLS variable includes: Get the starting address of the global offset table; Traversing the code segments in the dynamic link library; when a matching code segment matching the preset byte rule information is found in the code segments, determining a relocation search address based on an offset address of the matching code segment and the starting address; Based on the relocation search address, the variable name of the first TLS variable and the assembly code position of the first TLS variable are searched from the relocation list stored in the dynamic link library.

[0010] In some embodiments, obtaining the target assembly code accessed based on the second access mode according to the TLS variable offset includes: Determine the pointer offset of the thread control block TCB pointer according to the last TLS variable in the executable file; Determining a target offset of the first TLS variable relative to the TCB pointer based on the pointer offset and the TLS variable offset; Based on the target offset, a target assembly code accessed based on the second access mode is obtained.

[0011] In some embodiments, switching the searched first TLS variable from the first access mode to the second access mode to generate a second TLS variable includes: The first TLS variable is switched from the first access mode to the second access mode, and the relocation information corresponding to the first TLS variable is converted from a dynamic relocation type to a static relocation type, and the second TLS variable is generated.

[0012] In some embodiments, the step of jumping to execute the patch function based on the dynamic link library and calling the second TLS variable includes: The dynamic link library is used to modify the entry instruction of the defective function in the target process, jump to execute the patch function, and call the second TLS variable in the patch function.

[0013] In some embodiments, the first access mode is GD mode, and / or the second access mode is LE mode.

[0014] In a second aspect, an embodiment of the present application provides a patch function loading device, including: Compilation module, used to compile patch functions to generate dynamic link libraries; A mode detection module, used for searching the first thread local storage TLS variable of the patch function from the dynamic link library; the first TLS variable is a TLS variable in a first access mode, and the first access mode is an access mode of relocation dependency; A mode switching module, used for switching the searched first TLS variable from the first access mode to a second access mode to generate a second TLS variable; the second access mode is an access mode for canceling the relocation dependency; A patch loading module is used to jump to execute the patch function based on the dynamic link library and call the second TLS variable.

[0015] In a third aspect, an embodiment of the present application provides a storage medium on which a computer program is stored, and when the program is executed by a processor, the method for loading the patch function as described in the first aspect above is implemented.

[0016] Compared with the related art, the patch function loading method, device and storage medium provided in the embodiment of the present application generate a dynamic link library by compiling the patch function; from the dynamic link library, search for the first thread-local storage TLS variable of the patch function; the first TLS variable is a TLS variable in a first access mode, and the first access mode is an access mode of relocation dependency; the searched first TLS variable is switched from the first access mode to the second access mode to generate a second TLS variable; the second access mode is an access mode of canceling the relocation dependency; based on the dynamic link library, jump to execute the patch function and call the second TLS variable. Based on this, the access mode of the TLS variable can be unified, and the relocation addressing method of the TLS variable in the LE mode defined in the executable file of the TLS thread variable in the GD mode in the dynamic link library is realized, and the relocation dependency of the TLS variable in the patch function is eliminated, and finally the function patch using the TLS variable can be successfully loaded, thereby effectively solving the problem that it is difficult to effectively reduce the dependency of the TLS variable on relocation in the hot patch loading method using the TLS variable.

[0017] Details of one or more embodiments of the present application are set forth in the following drawings and description to make other features, objects, and advantages of the present application more readily apparent. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings: Figure 1 It is a hardware structure block diagram of a terminal according to a method for loading a patch function in an embodiment of the present application; Figure 2 is a flow chart of a method for loading a patch function according to an embodiment of the present application; Figure 3 is a schematic diagram of loading a patch function according to an embodiment of the present application; Figure 4 is a flow chart of a method for determining an access mode of a TLS variable according to an embodiment of the present application; Figure 5 is a flowchart of a method for obtaining a variable name of a TLS variable according to an embodiment of the present application; Figure 6 is a schematic diagram of a storage method of a TLS variable in a thread local storage space according to an embodiment of the present application; Figure 7 is a flow chart of a method for switching access modes of TLS variables according to an embodiment of the present application; Figure 8 It is a structural block diagram of a patch function loading device according to an embodiment of the present application. DETAILED DESCRIPTION

[0019] In order to make the purpose, technical solutions and advantages of the present application clearer, the present application is described and illustrated below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not intended to limit the present application. Based on the embodiments provided in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present application. In addition, it can also be understood that although the efforts made in this development process may be complex and lengthy, for ordinary technicians in the field related to the contents disclosed in the present application, some changes such as design, manufacturing or production based on the technical contents disclosed in the present application are only conventional technical means, and should not be understood as insufficient contents disclosed in the present application.

[0020] Reference to "embodiments" in this application means that a particular feature, structure, or characteristic described in conjunction with the embodiments may be included in at least one embodiment of the present application. The appearance of the phrase in various locations in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It is explicitly and implicitly understood by those of ordinary skill in the art that the embodiments described in this application may be combined with other embodiments without conflict.

[0021] Unless otherwise defined, the technical terms or scientific terms involved in this application should be understood by people with ordinary skills in the technical field to which this application belongs. The words "one", "a", "a", "the" and the like involved in this application do not indicate a quantity limitation, and may indicate the singular or plural. The terms "include", "comprise", "have" and any of their variations involved in this application are intended to cover non-exclusive inclusions; for example, a process, method, system, product or device that includes a series of steps or modules (units) is not limited to the listed steps or units, but may also include steps or units that are not listed, or may also include other steps or units inherent to these processes, methods, products or devices. The words "connect", "connected", "coupled" and the like involved in this application are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. The "multiple" involved in this application means greater than or equal to two. "And / or" describes the association relationship of associated objects, indicating that there can be three relationships. For example, "A and / or B" can mean: A exists alone, A and B exist at the same time, and B exists alone. The terms "first", "second", "third" and the like involved in the present application are merely used to distinguish similar objects and do not represent a specific ordering of the objects.

[0022] The method embodiment provided in this embodiment can be executed in a terminal, a computer or a similar computing device. Taking running on a terminal as an example, Figure 1 1 is a hardware structure block diagram of a terminal according to a method for loading a patch function in an embodiment of the present application. Figure 1 As shown, the terminal may include one or more ( Figure 1 Only one is shown in the figure) a processor 102 (the processor 102 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA) and a memory 104 for storing data. Optionally, the terminal may also include a transmission device 106 and an input / output device 108 for communication functions. It can be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the above terminal. Figure 1 More or fewer components as shown, or with Figure 1 Different configurations are shown.

[0023] The memory 104 can be used to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the loading method of the patch function in the embodiment of the present application. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, that is, to implement the above method. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include a memory remotely arranged relative to the processor 102, and these remote memories may be connected to the terminal via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0024] The transmission device 106 is used to receive or send data via a network. The specific example of the above network may include a wireless network provided by a communication provider of the terminal. In one example, the transmission device 106 includes a network adapter (Network Interface Controller, referred to as NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission device 106 can be a radio frequency (Radio Frequency, referred to as RF) module, which is used to communicate with the Internet wirelessly.

[0025] The following are explanations of some of the terms that appear in the text: (1) Dynamic linking: Dynamic linking refers to compiling and linking a function into a dynamic link library. The function's running address is not determined after compilation and linking. The final running address of the function can only be determined after the process is loaded. Dynamic linking can achieve the sharing of a dynamic library code in each loading process, saving memory space.

[0026] (2) TLS variables: TLS is a thread-level storage mechanism that allows each thread to have its own private variables at runtime. These variables can only be accessed by the thread and are not shared by other threads. These private variables are called TLS variables. TLS variables stored locally in a thread are not as easily opened to the process as ordinary global variables. Global variables accessed by any thread in the process are in the same memory space. TLS variables need to be constructed in a separate space created for each thread, and the memory space of TLS variables accessed by different threads is different.

[0027] (3) TLS variable access mode: The access mode of TLS variables determines how to access data in thread local storage. The access mode of TLS variables may be different in different programming environments and compilers. The following are some common TLS variable access modes: GD mode: In GD mode, access to TLS variables is achieved through global indirect references. Usually, each thread has a pointer to its TLS data, and access to TLS variables requires offset calculation through this pointer. It is suitable for TLS variables that need to span multiple modules or libraries.

[0028] Local Dynamic (LD) mode: In LD mode, TLS variables are accessed through local indirect references. Similar to GD mode, but the indirection of access is implemented inside the module or library. Applicable to TLS variables inside modules or libraries.

[0029] Initial Exec (IE) mode: In IE mode, the address of the TLS variable is determined at program startup and remains unchanged throughout the execution of the program. This means that access to TLS variables can be achieved through direct address access without any indirect references. This mode has the highest performance because direct address access is usually faster than indirect references. However, since the address is determined at program startup, it may not be suitable for scenarios where TLS variables need to be dynamically allocated.

[0030] LE mode: Similar to IE mode, but it is for TLS variables inside modules or libraries. In this mode, the address of TLS variables is also determined when the module or library is loaded and remains unchanged. This mode has higher performance because TLS variables are also accessed through direct addresses. It is suitable for TLS variables inside modules or libraries.

[0031] (4) GOT (Global Offset Table): The GOT includes the space allocated for storing the actual running virtual address of the function. When linking an external function, the jump instruction does not jump directly to the final address of the external function, but jumps to the space allocated by the GOT table for storing the actual running virtual address of the external function.

[0032] In the related art, when using a dynamic link library to load a patch function, the most common access mode for TLS variables is the GD mode, which passes two parameters, the module ID and the TLS block offset, determined when the dynamic linker runs relocation, to the _tls_get_addr function; the _tls_get_addr function is a function used to obtain the address of a thread-local variable, and the access address of the corresponding TLS variable in the current thread can be calculated through the _tls_get_addr function. The most common application of the GD mode is the use of TLS variables by functions in dynamic link libraries.

[0033] Through the strict definition of TLS variables and usage scenarios, the LE mode is optimized. This mode can only reference TLS variables defined in executable files. When linking, the connector can calculate the relative offset of each TLS variable relative to the thread control block (TCB) pointer. When addressing, the TCB pointer is found, and the offset value is added to find the address of the TLS variable without relocation. The most common application scenario of LE mode is the use of TLS variables defined in executable files by functions compiled in a static linking manner.

[0034] Since LE mode does not require relocation, and GD mode addressing relies on the module ID and TLS block offset used for relocation, TLS variables in GD mode cannot be relocated and found in LE mode. For example, TLS variable t_flg in GD mode cannot be relocated and addressed in LE mode. This means that if a patch function func_a uses the TLS variable t_flg, and if the patch function func_a is compiled into a dynamic link library, the patch function func_a in the dynamic link library uses the GD mode to address the TLS variable t_flg, and t_flg is defined in the executable file, and the executable file uses the LE method compiled in a static link mode to address t_flg, resulting in t_flg having no relocation information; the final result is that for the TLS variable t_flg addressed by GD mode in the patch function func_a, since there is no relocation information for LE mode t_flg defined in the executable file, relocation addressing is impossible, and patch loading fails.

[0035] Based on this, this embodiment provides a method for loading a patch function. Figure 2 is a flowchart of a method for loading a patch function according to an embodiment of the present application, such as Figure 2 As shown, the process includes the following steps: Step S210, compile the patch function to generate a dynamic link library.

[0036] Among them, the patch function (i.e., the function used to fix the defect) and the patched function (i.e., the defect function) have the same name, and the patch function is compiled into a dynamic link library in a dynamic link manner. With the dynamic link library, as long as the function prototype of the original function corresponding to the patch function in the patch code remains unchanged, the dynamic link library can be directly loaded into its version without modification, so that a single patch code can be used in multiple application versions.

[0037] Specifically, a code including one or more patch functions is written and compiled into a dynamic link library. The patch function may be a function that fixes certain problems or a custom function for a specific purpose.

[0038] Step S220, searching the dynamic link library for a first TLS variable of the patch function; the first TLS variable is a TLS variable in a first access mode, and the first access mode is an access mode of relocation dependency.

[0039] After the dynamic link library is compiled, it is necessary to search for the TLS variables used in the patch function. First, the exact location and identification of the TLS variables in the patch function need to be known. This usually includes the index of the TLS variable (offset in the TLS block) and the thread local storage segment to which it belongs. This information can be obtained through the tools or options provided by the compiler when compiling the patch function, or inferred by reverse engineering the dynamic link library.

[0040] During the TLS variable search process, since the dynamic link library describes the relocation related information, the relocation information also describes the layout and properties of the TLS variable; therefore, the relocation information can be parsed, and the corresponding entry can be found in the TLS relocation information according to the known TLS variable index, and the access mode of the relocation dependency of the TLS variable can be determined. Relocation dependency means that the address of the TLS variable may change at runtime, which is usually caused by the relocation of the dynamic link library or the change of the load address. Among them, the detection method for the access mode of the TLS variable can be: search for the relocation item related to the TLS variable in the relocation table of the dynamic link library, and determine the access mode of the TLS variable according to the search result.

[0041] Furthermore, the first access mode may be a GD mode.

[0042] Step S230, switching the searched first TLS variable from the first access mode to the second access mode to generate a second TLS variable; the second access mode is an access mode that cancels the relocation dependency.

[0043] It should be noted that for the second TLS variable in the second access mode, since the linker can calculate the relative offset of each TLS variable relative to the Thread Control Block (TCB) pointer when linking, the TCB pointer can be directly found when addressing, and the address of the TLS variable can be found by adding the relative offset value without relocation. Since the second access mode does not require relocation, and the first access mode addressing relies on the module ID and TLS block offset used for relocation, the first TLS variable in the first access mode cannot be relocated and addressed in the second access mode.

[0044] Based on this, in order to effectively solve the problem of relocation dependency in the patch loading process, in this step, the TLS variable used in the code segment of the patch function in the dynamic link library can be switched from the first access mode to the second access mode. Specifically, the variable name information and the code starting position of the first TLS variable are determined, and the TIS variable with the same name is searched in the executable file to obtain the offset value of the TLS variable relative to the TCB pointer, and the assembly code to be replaced is determined based on the offset value; finally, based on the above-determined code starting position, the assembly code of the first TLS variable in the dynamic link library is replaced with the above-determined assembly code to be replaced, thereby realizing the conversion method of converting the TLS variable from the first access mode to the second access mode in the dynamic link library.

[0045] Furthermore, the second access mode may be an LE access mode; the most common application scenario of the LE mode is the use of TLS variables defined in an executable file by functions compiled in a static linking manner.

[0046] Step S240: Based on the dynamic link library, jump to execute the patch function and call the second TLS variable.

[0047] Specifically, see Figure 3 , the target process includes the patched function func A and the function func B that calls the defective function funcA. The defective function func A contains the push rbp instruction; the push rbp instruction is an assembly language instruction used to operate on the x86-64 architecture processor. The function of this instruction is to push the value of the current base pointer register (BP register for short, extended to RBP register in 64-bit mode) into the stack. During the hot patch loading process, the patch file is dynamically loaded by the patched process in a dynamic loading manner, and the patch function information implemented in the patch file is read. According to the function name, all functions used in the patched target process are searched for the same-name function. The found function with the same name is the function that needs to be patched. After the access mode of the TLS variable is successfully switched, the code in the target process will use the dynamic link library to jump to execute the patch function with the same name as the defective function of the patched process based on the second TLS variable. The jump operation may involve modifying the entry point of the defective function in the target process to point to the address of the patch function. Also, since TLS variables are now accessed in a way that eliminates relocation dependencies, the patched function is able to safely read and write its thread-specific data.

[0048] Among them, the assembly instructions at the function address entry of the patch function in the patched process are modified, the assembly instruction content is modified to jump to the function address of the same name implemented in the patch dynamic link library, and the relevant instructions for calling the second TLS variable are executed, thereby replacing the patched function and finally completing the defect repair.

[0049] In the above-mentioned loading method of the patch function, by searching whether there is a first TLS variable in the first access mode in the dynamic link library, and switching the searched first TLS variable from the first access mode to the second access mode, the access mode of the TLS variable can be unified, and the relocation addressing method of the TLS thread variable in the GD mode in the dynamic link library and the TLS variable in the LE mode defined in the executable file is realized, which eliminates the dependency on the relocation of the TLS variable in the patch function, and finally the function patch using the TLS variable can be successfully loaded.

[0050] In some embodiments, the above step of searching the first TLS variable of the patch function from the dynamic link library further includes the following steps: From the dynamic link library, obtain the variable name of the TLS variable to be detected of the patch function; based on the variable name of the TLS variable to be detected, search whether there is matching relocation information from the relocation list stored in the dynamic link library; when matching relocation information is found, determine that the TLS variable to be detected is the first TLS variable.

[0051] The symbol information of the executable file is parsed according to the Executable and Linkable Format (ELF) format. If the symbol type is the symbol representation type of the preset TLS variable, such as STT_TLS, it indicates that the symbol is a TLS variable. The relocation table is searched according to the symbol name of the TLS variable. If there is no relocation information with the same name, it means that the TLS variable in the executable file is used in the second access mode. Otherwise, it means that the TLS variable is used in the first access mode.

[0052] The following is a description of the specific embodiments. Take the first access mode as GD mode and the second access mode as LE mode as an example. Figure 4 The above process of determining the access mode of the TLS variable in the executable file includes the following steps: Step S401, start the process; parse the symbol information of the executable file according to the ELF format, and determine whether the symbol type of the variable currently traversed is STT_TLS; if not, end the process.

[0053] Among them, an equivalent approach to parsing the symbols of the executable file in ELE format to determine whether the symbol type is STT_TLS to find TLS variables is to determine whether the Type field is TLS through the output of "readelf -s executable file name". If it is, it indicates that the symbol is a TLS variable. For example, as shown below, by filtering with the "readelf -s process_a | grepTLS" command, you can see that variables such as t_InSoflg in the executable file are all TLS variables.

[0054]

[0055] Step S402, if the judgment result of the above step S401 is yes, it is determined that the traversed variable is a TLS variable, and the relocation list is searched for a symbol with the same name according to the symbol name; if not, it is determined that the TLS variable is used in the second access mode, and the process ends.

[0056] Among them, an equivalent method to find information from the relocation table is to view the relocation information through "readelf -Wr executable file name". For example, after confirming that t_InSoflg is the TLS variable of the executable file process_a, the relocation information output by "readelf -r process_a" is searched. No information with the same name is found, indicating that the TLS variable t_InSoflg is used in LE mode.

[0057]

[0058] Step S403: If the judgment result of the above step S402 is yes, it is determined that the TLS variable is used in the GD mode.

[0059] Through the above embodiment, the variable name of the TLS variable to be detected of the patch function is obtained, and the matching relocation information is searched from the relocation list of the dynamic link library, which can accurately determine which TLS variables are relocation dependent, avoiding the uncertainty that may be caused by address-based matching. In addition, using variable names for matching can ensure that only TLS variables that are truly related to relocation are identified as the first TLS variable, thereby reducing the possibility of false positives and false negatives, thereby effectively improving the accuracy of patch function loading.

[0060] In some embodiments, the switching of the searched first TLS variable from the first access mode to the second access mode to generate the second TLS variable may further include the following steps: Obtain an executable file of a target process; the target process is a process of an application program that loads a patch function at runtime; from the executable file, search for a variable with the same name as the first TLS variable, and based on the variable with the same name, determine the TLS variable offset of the first TLS variable in the thread local storage space; according to the TLS variable offset, obtain a target assembly code accessed based on a second access mode; based on the assembly code position of the first TLS variable, replace the first TLS variable with the target assembly code, and generate a second TLS variable.

[0061] Since the length of the binary assembly code compiled by accessing TLS variables in GD mode and LE mode is the same, which is 12 bytes, the variable name and the starting position of the binary assembly code are obtained in the dynamic link library, and the variable name is used to determine whether the variable uses GD mode in the executable file. If not, it means that there is no relocation information and there is no need to switch to LE mode. If it is GD mode, for the first TLS variable in the GD mode that is searched, according to the variable name, search for the TLS variable with the same name in the executable file in the ELF file format (for example, it can be obtained by the readelf -s executable file name method), and determine the offset of the TLS variable with the same name in the thread local storage space, and determine the offset of the TCB pointer according to the offset and length of the last TLS variable and the number of aligned bytes. The offset of the TCB pointer minus the offset of the TLS variable can obtain the offset value of the TLS variable relative to the TCB pointer, and the offset value replaces the last four bytes of the binary assembly code 65 a1 0000 00 00 81 e8 14 40 00 00 (the last four bytes 1440 00 00 are the offset value represented in little endian) of the LE mode TLS variable access, and generates the corresponding LE mode binary assembly code of the TLS variable. Replace the 12-byte LE mode assembly code from the starting position of the binary assembly code obtained above, and the TLS variable used in the GD mode in the dynamic library can be modified to the TLS variable used in the LE mode.

[0062] For example, the access assembly instructions of the TLS variable t_InSoflg in GD mode are as follows:

[0063] The access assembly instruction of LE mode TLS variable t_InSoflg is:

[0064] According to the method for determining the TLS variable name used by a function from a dynamic link library described in the above embodiment, it is obtained that in the dynamic link library libhotpatchtest.so, the 12 bytes starting from the code segment 0x852 (8d 04 1d dc ff ff ff e8e2 fd ff ff) are the TLS variable t_InSoflg used in the GD mode. According to the variable name t_InSoflg, it is determined whether the variable t_InSoflg uses the GD mode in the executable file, and the offset of the variable t_InSoflg in the thread local storage space is determined to be 0x8008 in the executable file (process_a) in the ELF file format through the variable name t_InSoflg.

[0065] The offset of the last TLS variable t_InSoflgc in the thread local storage space in the entire executable file is 0xc018 and the length is 1. It can also be analyzed that the TLS variable is aligned to 4 bytes, so the offset of the TCB pointer is 0xc018+4=0xc01c. The offset of the TCB pointer 0xc01c minus the offset of the TLS variable t_InSoflg 0x8008 can be obtained. The relative TCB pointer of the TLS variable t_InSoflg is 0xc01c - 0x8008 = 0x4014 (14 4000 00 in hexadecimal little endian). This offset value replaces the last four bytes of the binary assembly code 65 a1 00 00 00 00 81 e800 00 00 00 for LE mode TLS variable access, and generates the binary assembly code 65 a1 0000 00 00 81e8 14 40 00 00 for LE mode of TLS variable t_flg (the last four bytes are 14 40 00 00 is the value 0x4014 represented by the little-endian sequence) Replace the 12-byte assembly code of the LE mode using the t_InSoflg variable starting from the code segment 0x852 in libhotpatchtest.so, and you can change the GD mode using the t_InSoflg variable in the dynamic library libhotpatchtest.so to the LE mode using the t_InSoflg variable.

[0066] Through the above embodiment, automatic switching of access modes to TLS variables based on assembly code replacement is realized. Compared with other methods such as directly modifying the internal structure of the dynamic link library, which may easily cause problems such as program crash, instability or malfunction, the above mode switching method effectively ensures the stability of the dynamic link library operation, thereby ensuring the stability and accuracy of patch loading.

[0067] In some embodiments, the variable name of the first TLS variable and the assembly code position of the first TLS variable may further include the following steps: Obtain the starting address of the GOT table; traverse the code segments in the dynamic link library; when a matching code segment matching the preset byte rule information is found in the code segment, determine the relocation search address based on the offset address of the matching code segment and the starting address; based on the relocation search address, search for the variable name of the first TLS variable and the assembly code position of the first TLS variable from the relocation list stored in the dynamic link library.

[0068] In this step, a set of byte rules (e.g., specific instruction sequences, opcodes, operands, etc.) can be defined, and these rules will be used to find matching code segments in the code segment. Use the byte rules to scan the content of the code segment to find matching code segments. For each matching code segment, record its offset address in the code segment. And parse the symbol table information of the dynamic link library libhotpatchtest.so in ELF format, the starting address of the _GLOBAL_OFFSET_TABLE_ symbol can be determined, that is, the starting address of the GOT table is obtained, and finally the relocation search address is determined by the above offset address and the starting address of the GOT table, and then the variable name and assembly code position of the first TLS variable can be found from the relocation list according to the calculated address.

[0069] It should be noted that, taking GD mode as an example, the TLS variable access method in this mode is as follows: In X86 type CPU, the function __tls_get_addr is called with a pointer parameter pointing to an object of type tls_index, and the access address of the corresponding TLS variable in the current thread can be calculated: extern void __tls_get_addr (tls_index 0 ti); The type tls_index is defined as follows: typedef struct dl_tls_index { unsigned long int ti_module; unsigned long int ti_offset; } tls_index; When linking, the linker allocates two members of the tls_index structure, ti_module and ti_offset, for each TLS variable and stores them in the GOT table (Global Offset Table). The member ti_module is associated with the relocation type R_386_TLS_DTPMOD32 of the TLS variable, and the member ti_offset is associated with the relocation type R_386_TLS_DTPOFF32 of the TLS variable: For example, in the ELF format dynamic link library libhotpatchtest.so, you can see the relocation information in the dynamic link library through the readelf -Wrlibhotpatchtest.so command. The R_386_TLS_DTPMOD32 type offset address of the TLS variable t_InSoflg is 0x0000001fdc, indicating that the ti_module information of the t_InSoflg variable is stored in the GOT table at the position of 0x0000001fdc, and the R_386_TLS_DTPOFF32 type offset address of the TLS variable t_InSoflg is 0x0000001fe0, indicating that the ti_offset information of the t_InSoflg variable is stored in the GOT table at the position of 0x0000001fe0. One example of the GOT table is as follows:

[0070] The difference between 0x0000001fdc and 0x0000001fe0 is 4 bytes, which is exactly the length of the ti_module member. Therefore, the 8-byte continuous space starting from the address 0x0000001fdc in the GOT table is used to store the tls_index information of the t_InSoflg variable. When the assembly code is implemented, the address 0x0000001fdc is found and stored in the register eax that passes the first function parameter. Then the __tls_get_addr function is called to get the access address of the TLS variable t_InSoflg in the current thread.

[0071] The following is an example of the binary assembly code implementation of accessing the TLS variable t_InSoflg compiled in GD mode:

[0072] In the fourth line, e8 5d fe ff ff at 0x82e indicates the instruction to call the __x86.get_pc_thunk.bx function at 690 (the first byte 0xe8 indicates that the function is called using the call instruction, and the following four bytes 0x5d fe ff ff are little-endian complements representing the negative number -419, which is the difference between the instruction value at __x86.get_pc_thunk.bx, which is 0x690 in hexadecimal (1680 in decimal), and the next instruction, which is 0x833 in hexadecimal (2099 in decimal), called. The __x86.get_pc_thunk.bx function can get the address of the next instruction, 0x833, and assign it to the ebx register.

[0073] At 0x833 in the fifth line, 81 c3 cd 17 00 00 indicates that the value of the extended base register (ebx register) 0x833 plus the value of 0x17cd (the last 4 bytes of the line 0xcd170000 is 0x17cd in little endian) is assigned to the ebx register as 0x2000. By parsing the symbol table information of the dynamic link library libhotpatchtest.so in ELF format, we can see that 0x2000 is the starting address of the _GLOBAL_OFFSET_TABLE_ symbol.

[0074] At 0x852 in the seventh line, 8d 04 1d dc ff ff ff means that the product of the value of the ebx register 0x2000 multiplied by 1 plus the negative number -0x24 (the last 4 bytes of the line 0xdcffffff is the negative number -0x24 represented by the little endian complement) is 0x1fdc, which is assigned to the eax register. At this time, the value in the register eax passed by the function call as the first parameter is the position 0x1fdc of the t_InSoflg variable ti_module information in the GOT table.

[0075] At 0x859 in the eighth line, e8 e2 fd ff ff implements the function of calling the __tls_get_addr interface. In this way, the access address of the TLS variable t_InSoflg in the current thread can be obtained.

[0076] Therefore, by parsing the symbol table information of the dynamic link library libhotpatchtest.so in ELF format, the starting address of the _GLOBAL_OFFSET_TABLE_ symbol can be obtained. An equivalent approach is as follows: the address 0x2000 of the _GLOBAL_OFFSET_TABLE_ symbol can be obtained by using the readelf -Wslibhotpatchtest.so command, for example:

[0077] After getting the starting address of the _GLOBAL_OFFSET_TABLE_ symbol, traverse the code segment of the dynamic link library libhotpatchtest.so in ELF format. If, like at 0x852, there is a code segment with the first 2 bytes being 0x8d 0x04 (the assembly instruction of 0x8d 0x04 indicates lea M %eax, which is used to calculate the offset value and assign it to the register eax, which is the first parameter passed when calling a function) and the 8th byte being 0xe8 (the assembly instruction of 0xe8 indicates that the call instruction calls a function. If the called function is ___tls_get_addr@plt, the value of the TLS variable can be obtained), take the 4 consecutive bytes starting from the 4th byte (for example, dc ff ff ff is a negative number represented by the little endian complement code -0x24) The value is the offset (-0x24) plus the starting address value of the _GLOBAL_OFFSET_TABLE_ symbol (0x2000), which is 0x1fdc. Look it up in the relocation table of type R_386_TLS_DTPMOD32. If it is consistent with the Offset field value of a TLS variable in the relocation table (0x1fdc of t_InSoflg), it can be determined that the variable operated in the code segment is t_InSoflg and the starting address of the binary assembly code is 0x852. For example:

[0078] According to the above rules, we can determine the method of obtaining the TLS variable name used by the function from the dynamic link library. Specifically, by parsing the symbol table information of the dynamic link library libhotpatchtest.so in ELF format, we can get the starting address of the _GLOBAL_OFFSET_TABLE_ symbol, traverse the code segment, and according to the matching conditions: the 1st to 2nd bytes are 0x8d 0x04, the 8th byte is e8, and the 4th to 7th bytes are the offset values ​​relative to the starting address of the _GLOBAL_OFFSET_TABLE_ symbol in little endian. The offset value plus the starting address of the _GLOBAL_OFFSET_TABLE_ symbol is the result. If the result is searched in the relocation table of the R_386_TLS_DTPMOD32 type, if it is consistent with the Offset field value of a TLS variable, the variable name information and the location of the binary assembly code of the TLS variable that needs to be obtained in the current code segment can be matched.

[0079] The following describes a method for determining a TLS variable name used by a function in a dynamic link library in conjunction with a specific embodiment; Figure 5 As shown, the method flow includes the following steps: Step S501, start the process; parse the symbol table information of the dynamic link library libhotpatchtest.so according to the ELF format to obtain the starting address of the _GLOBAL_OFFSET_TABLE_ symbol, that is, the starting address of the global offset table.

[0080] Step S502, traverse the memory of the code segment of the dynamic link library.

[0081] Step S503, determine whether the first byte to the second byte is 0x8d0x04, and whether the eighth byte is 0xe8 (ie, the above-mentioned byte rule information). If not, end the process.

[0082] Step S504, if the judgment result of the above step S503 is yes, then determine whether the Offset field is consistent in the relocation table based on the offset value of the 4th byte to the 7th byte relative to the starting address of the global offset table in the little endian order plus the calculation result of the starting address of the global offset table. Specifically, determine whether the code segment with the offset value of the 4th byte to the 7th byte relative to the starting address of the _GLOBAL_OFFSET_TABLE_ symbol plus the calculation result of the starting address of the _GLOBAL_OFFSET_TABLE_ symbol can be found in the relocation table of the R_386_TLS_DTPMOD32 type. If not, end the process.

[0083] Step S505: If the judgment result of the above step S504 is yes, the variable name information of the TLS variable that needs to be obtained in the current code segment and the location of the binary assembly code can be matched to determine.

[0084] In some embodiments, the obtaining of the target assembly code based on the second access mode access according to the TLS variable offset may further include the following steps: According to the last TLS variable in the executable file, the pointer offset of the thread control block TCB pointer is determined; according to the pointer offset and the TLS variable offset, the target offset of the first TLS variable relative to the TCB pointer is determined; based on the target offset, the target assembly code accessed based on the second access mode is obtained.

[0085] It should also be noted that the access method for TLS variables in LE mode is as follows: See also Figure 6, Thread 1 and Thread 2 both have their own TLS variable thread local storage (TLS) space at runtime. These TLS variable thread local storage spaces can only be accessed by their own threads and are not shared by other threads. When the linker links, it arranges the memory space of each thread variable and thread control block (TCB). For example, in the thread local storage space, TLS variable 1 has an offset of 0 and a length of 4, TLS variable 2 has an offset of 4 and a length of 4, TLS variable N has an offset of 28 and a length of 4, and the offset of the TCB pointer is 32 (0x20). When actually accessing the TLS variable, first get the address of the TCB pointer, add the relative offset, and you can get the address of the TLS variable, and then access the TLS variable. For example, the address of the TCB pointer of thread 1 is 0x40020. If you need to access TLS variable 1, calculate the offset of TLS variable 1 as 0–0x20=-0x20, and you can calculate the address of TLS variable 1 as 0x40020-0x20=0x40000.

[0086] In the X86 CPU compilation product, you can use "readelf -s executable file (for example, process_a)" to see the information of each TLS variable defined in the executable file, as shown in the following code example:

[0087] In the above example, the value of the Type item in the fourth column is TLS, indicating that the variable is a TLS variable. The value of the Name item in the eighth column is the name of the TLS variable. The value of the Size item in the third column is the length of the TLS variable in bytes. The value of the Value item in the second column is the offset of each TLS variable in the thread local storage space. For example, the offset of the TLS variable t_InSoflg in the thread local storage space is 0x8008, and the length is 4.

[0088] In the X86 type CPU compilation product, the gs register is used to store the address of the TCB pointer. If you need to access the TLS variable, first get the value of the fs register to get the address of the TCB pointer, then get the offset of the TLS variable in the thread local storage space and the offset of the TCB pointer, calculate the offset difference, and add the value of the TCB pointer to this offset difference to get the address of the TLS variable, and then access its content.

[0089] The following is an example of the 12-byte binary assembly code compiled to access the TLS variable t_InSoflg:

[0090] The instruction 65 a1 00 00 00 00 in the first line gets the TCB pointer address stored in the gs register and stores it in the eax register. The offset of the t_InSoflg variable in the thread local storage space is 0x8008. The offset of the last TLS variable t_InSoflgc in the thread local storage space of the entire executable file is 0xc018, and the length is 1. It can also be analyzed that the TLS variable is aligned to 4 bytes, so the offset of the TCB pointer is 0xc018+4=0xc01c. It can be calculated that the offset from the t_InSoflg variable to the TCB pointer is 0xc01c - 0x8008 = 0x4014, and the instruction 81 e8 14 40 00 00 in the second line of the assembly code is to subtract 4014 from the TCB pointer address stored in the rax register (the last four-byte instruction 14 40 00 00 is 0x4014 in little endian) and then store it back in the rax register to get the address of the t_InSoflg variable. The t_InSoflg variable can be accessed through this address later.

[0091] The following describes the mode switching process in conjunction with a specific embodiment. Figure 7 , the process includes the following steps: Step S701, start the process; according to the method of determining the variable name of the TLS variable used by the function from the dynamic link library described in the above embodiment, obtain the variable name and the starting position of the binary assembly code.

[0092] Step S702: According to the variable name, determine in the executable file whether the TLS variable uses the GD mode. If not, it means that there is no need to switch the access mode for the TLS variable, and the process can be terminated.

[0093] Step S703: If the judgment result of the above step S703 is yes, then according to the variable name, a TLS variable with the same name is searched in the executable file of the ELF file format to obtain the offset of the TLS variable in the thread local storage space.

[0094] Step S704: Determine the offset of the TCB pointer according to the offset and length of the last TLS variable in the execution file and the number of aligned bytes.

[0095] Step S705, the offset of the TCB pointer minus the offset of the TLS variable is obtained to obtain the offset of the TLS variable relative to the TCB pointer, and its value replaces the last four bytes of the binary assembly code 65 a1 00 00 00 00 81 e8 00 00 00 00 for accessing the LE mode TLS variable to generate the corresponding LE mode binary assembly code of the TLS variable.

[0096] Step S706, replace the 12-byte LE mode assembly code from the starting position of the binary assembly code obtained above, so that the GD mode using TLS variables in the dynamic library can be modified to the LE mode using TLS variables; end the process.

[0097] In some embodiments, the switching of the searched first TLS variable from the first access mode to the second access mode to generate the second TLS variable may further include the following steps: The first TLS variable is switched from the first access mode to the second access mode, and the relocation information corresponding to the first TLS variable is converted from the dynamic relocation type to the static relocation type, and a second TLS variable is generated.

[0098] It should also be noted that when the TLS variable in the dynamic link library is switched from the first access mode to the second access mode, the relocation type in the relocation information should also be converted accordingly to prompt the operation information. The second TLS variable does not need to be relocated, thereby avoiding the problem that the operating system still searches according to the relocation type, resulting in failure to load the dynamic link library.

[0099] For example, after switching the TLS variable from the GD mode to the LE mode according to the steps described in any of the above embodiments, the relocation type of the TLS variable in the relocation information is detected, for example:

[0100] In the above code, .. / is a path notation, which refers to the parent directory of the current directory. The relocation information in t_InSoflg in the above code needs to be modified to R_386_RELATIVE type, so that the operating system will not relocate t_InSoflg and can be loaded successfully. The modified relocation information of the dynamic link library is as follows:

[0101] Through the above embodiment, while the access mode of the TLS variable is automatically switched, the relocation information of the dynamic link library is also modified accordingly, thereby ensuring that the operating system can find the TLS variable according to the modified relocation type after the mode is switched, and effectively avoiding the problem of patch function loading failure caused by unsynchronized relocation type.

[0102] In some embodiments, the above-mentioned jump execution of the patch function based on the dynamic link library and calling the second TLS variable may also include the following steps: The dynamic link library is used to modify the entry instruction of the defective function in the target process, jump to execute the patch function, and call the second TLS variable in the patch function.

[0103] In LE access mode, the second TLS variable is a thread-specific variable used to store thread-unique data. The address or addressing mode of the second TLS variable in memory is determined by static linking, that is, based on information known at compile time. This process usually involves parsing symbol tables or other metadata generated by compilers and linkers.

[0104] During the patch loading process, ensure that the required dynamic link library has been correctly loaded into the address space of the target process. Use the mechanisms provided by the dynamic link library (such as hook functions, inline assembly, or other low-level operations) to modify the entry point of the defective function in the target process. This usually involves replacing the original entry instruction of the defective function with a jump instruction. The target address of the jump instruction is set to the address of the patch function, which needs to be calculated based on the previously determined addressing information (which may be a direct address or an offset relative to a known point).

[0105] When the code in the target process executes to the entry of the modified defective function, a jump instruction is triggered and the control flow is transferred to the patch function. The patch function executes the corresponding repair logic according to the thread-specific data stored in the second TLS variable. After executing the patch function, the control flow can return to a certain point in the original code path (if necessary), or continue to execute other code after the patch function.

[0106] Through the above embodiment, a hot patch loading method using TLS variable functions is provided, and TLS variables are used to perform hot patch loading and replacement of functions when the process is running, thereby repairing defective functions and completing defective software repair without restarting the device.

[0107] It should be noted that the steps shown in the above process or the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0108] This embodiment also provides a patch function loading device, which is used to implement the above embodiments and preferred implementations, and will not be repeated here. As used below, the terms "module", "unit", "subunit", etc. can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceivable.

[0109] Figure 8 is a structural block diagram of a patch function loading device according to an embodiment of the present application, such as Figure 6 As shown, the device comprises: A compilation module 81 is used to compile a patch function to generate a dynamic link library; a mode detection module 82 is used to search for a first thread-local storage TLS variable of the patch function from the dynamic link library; the first TLS variable is a TLS variable in a first access mode, and the first access mode is an access mode of relocation dependency; a mode switching module 83 is used to switch the searched first TLS variable from the first access mode to the second access mode to generate a second TLS variable; the second access mode is an access mode of canceling relocation dependency; a patch loading module 84 is used to jump to execute the patch function based on the dynamic link library, and call the second TLS variable.

[0110] In some of the embodiments, the pattern detection module 82 is also used to obtain the variable name of the TLS variable to be detected of the patch function from the dynamic link library; the pattern detection module 82 is also used to search whether there is matching relocation information from the relocation list stored in the dynamic link library based on the variable name of the TLS variable to be detected; when matching relocation information is found, it is determined that the TLS variable to be detected is the first TLS variable.

[0111] In some of the embodiments, the mode switching module 83 is also used to obtain an executable file of a target process; the target process is a process of an application that loads a patch function at runtime; the mode switching module 83 is also used to search for a variable with the same name as the first TLS variable from the executable file, and based on the variable with the same name, determine the TLS variable offset of the first TLS variable in the thread local storage space; the mode switching module 83 is also used to obtain a target assembly code accessed based on a second access mode according to the TLS variable offset; the mode switching module 83 is also used to replace the first TLS variable with the target assembly code based on the assembly code position of the first TLS variable, and generate a second TLS variable.

[0112] In some of the embodiments, the mode switching module 83 is also used to obtain the starting address of the GOT table; the mode switching module 83 is also used to traverse the code segments in the dynamic link library; when a matching code segment matching the preset byte rule information is found in the code segment, the relocation search address is determined based on the offset address of the matching code segment and the starting address; the mode switching module 83 is also used to search for the variable name of the first TLS variable and the assembly code position of the first TLS variable from the relocation list stored in the dynamic link library based on the relocation search address.

[0113] In some of the embodiments, the mode switching module 83 is further used to determine a pointer offset of the TCB pointer based on the last TLS variable in the executable file; the mode switching module 83 is further used to determine a target offset of the first TLS variable relative to the TCB pointer based on the pointer offset and the TLS variable offset; the mode switching module is further used to obtain a target assembly code accessed based on the second access mode based on the target offset.

[0114] In some of the embodiments, the mode switching module 83 is also used to switch the first TLS variable from the first access mode to the second access mode, and to convert the relocation information corresponding to the first TLS variable from the dynamic relocation type to the static relocation type, and to generate a second TLS variable.

[0115] In some of the embodiments, the patch loading module 84 is further used to utilize a dynamic link library to modify the entry instruction of the defective function in the target process, jump to execute the patch function, and call the second TLS variable in the patch function.

[0116] It should be noted that the above modules can be functional modules or program modules, and can be implemented by software or hardware. For modules implemented by hardware, the above modules can be located in the same processor; or the above modules can be located in different processors in any combination.

[0117] This embodiment further provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.

[0118] Optionally, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0119] Optionally, in this embodiment, the processor may be configured to perform the following steps through a computer program: S1, compile the patch function to generate a dynamic link library.

[0120] S2, searching for a first thread local storage TLS variable of the patch function from the dynamic link library; the first TLS variable is a TLS variable in a first access mode, and the first access mode is an access mode of relocation dependency.

[0121] S3, switching the searched first TLS variable from the first access mode to the second access mode to generate a second TLS variable; the second access mode is an access mode that cancels the relocation dependency.

[0122] S4, based on the dynamic link library, jump to execute the patch function and call the second TLS variable.

[0123] It should be noted that the specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementation modes, and this embodiment will not be described in detail here.

[0124] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties.

[0125] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited to this. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, etc., but are not limited to this.

[0126] In addition, in combination with the patch function loading method in the above embodiment, the present application embodiment can provide a storage medium for implementation. The storage medium stores a computer program; when the computer program is executed by a processor, any of the patch function loading methods in the above embodiment is implemented.

[0127] Those skilled in the art should understand that the technical features of the above-described embodiments may be arbitrarily combined. To make the description concise, not all possible combinations of the technical features in the above-described embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0128] The above-mentioned embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the invention patent. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the patent of the present application shall be subject to the attached claims.

Claims

1. A method for loading a patch function, characterized in that: The method comprises: Compile the patch function to generate a dynamic link library; Searching for a first TLS variable of the patch function from the dynamic link library; the first TLS variable is a TLS variable in a first access mode, and the first access mode is an access mode of relocation dependency; Switching the searched first TLS variable from the first access mode to a second access mode to generate a second TLS variable; the second access mode is an access mode that cancels the relocation dependency; Based on the dynamic link library, the patch function is jumped and executed, and the second TLS variable is called.

2. The loading method according to claim 1, characterized in that: The step of searching the first thread local storage TLS variable of the patch function from the dynamic link library comprises: Obtaining, from the dynamic link library, a variable name of a TLS variable to be detected of the patch function; Based on the variable name of the TLS variable to be detected, whether there is matching relocation information is found from the relocation list stored in the dynamic link library; when the matching relocation information is found, it is determined that the TLS variable to be detected is the first TLS variable.

3. The loading method according to claim 1, characterized in that: The step of switching the searched first TLS variable from the first access mode to the second access mode to generate a second TLS variable includes: Obtaining an executable file of a target process; the target process is a process of an application program that loads the patch function at runtime; Searching for a variable with the same name as the first TLS variable from the executable file, and determining a TLS variable offset of the first TLS variable in the thread local storage space based on the variable with the same name; According to the TLS variable offset, obtaining a target assembly code accessed based on the second access mode; Based on the assembly code position of the first TLS variable, the first TLS variable is replaced with the target assembly code, and the second TLS variable is generated.

4. The loading method according to claim 3, characterized in that: Obtaining the variable name of the first TLS variable and the assembly code position of the first TLS variable includes: Get the starting address of the global offset table; Traversing the code segments in the dynamic link library; when a matching code segment matching the preset byte rule information is found in the code segments, determining a relocation search address based on an offset address of the matching code segment and the starting address; Based on the relocation search address, the variable name of the first TLS variable and the assembly code position of the first TLS variable are searched from the relocation list stored in the dynamic link library.

5. The loading method according to claim 3, characterized in that: The step of obtaining the target assembly code accessed based on the second access mode according to the TLS variable offset includes: Determine the pointer offset of the thread control block TCB pointer according to the last TLS variable in the executable file; Determining a target offset of the first TLS variable relative to the TCB pointer based on the pointer offset and the TLS variable offset; Based on the target offset, a target assembly code accessed based on the second access mode is obtained.

6. The loading method according to claim 1, characterized in that: The step of switching the searched first TLS variable from the first access mode to the second access mode to generate a second TLS variable includes: The first TLS variable is switched from the first access mode to the second access mode, and the relocation information corresponding to the first TLS variable is converted from a dynamic relocation type to a static relocation type, and the second TLS variable is generated.

7. The loading method according to claim 1, characterized in that: The step of jumping to execute the patch function based on the dynamic link library and calling the second TLS variable includes: The dynamic link library is used to modify the entry instruction of the defective function in the target process, jump to execute the patch function, and call the second TLS variable in the patch function.

8. The loading method according to any one of claims 1 to 7, characterized in that: The first access mode is a conventional dynamic GD mode, and / or the second access mode is a locally executable LE mode.

9. A patch function loading device, characterized in that: include: Compilation module, used to compile patch functions to generate dynamic link libraries; A mode detection module, used for searching the first TLS variable of the patch function from the dynamic link library; the first TLS variable is a TLS variable in a first access mode, and the first access mode is an access mode of relocation dependency; A mode switching module, used for switching the searched first TLS variable from the first access mode to a second access mode to generate a second TLS variable; the second access mode is an access mode for canceling the relocation dependency; A patch loading module is used to jump to execute the patch function based on the dynamic link library and call the second TLS variable.

10. A storage medium, characterized in that: The storage medium stores a computer program, wherein the computer program is configured to execute the method for loading a patch function according to any one of claims 1 to 8 when running.

Images