Hot patch loading method and related device

Abstract

The invention discloses a hot patch loading method and a related device, in the process of loading a first patch file in a dynamic link mode based on a second patch file, after relocation of a vulnerability function variable fails, the second patch file is compiled according to a static link mode, and the first patch file is loaded in the dynamic link mode. According to the method, the offset of the vulnerability function variable relative to the TCB pointer can be obtained, then the data in the address of the vulnerability function variable in the first patch file is updated by using the offset and the preset offset adjustment amount, and the second patch file is repaired according to the updated first patch file. The problem that in the dynamic linking process, the second patch file cannot be repaired after vulnerability function variable relocation fails is solved.

Description

Background Art

[0002] An application is a computer program developed to run on an operating system to complete a specific task. An application can include one or more processes, and each process can include one or more threads. In order to improve the execution efficiency of the application, multiple processes and multiple threads of each process can be executed concurrently.

[0003] Thread Local Storage (TLS) is a thread-level storage mechanism. TLS allows each thread to have its own variables at runtime. These variables can only be accessed by the corresponding thread and cannot be accessed by other threads. If a thread has TLS variables and a vulnerability exists in the thread that needs to be repaired, the patch file compiled by the dynamic link library is usually used to repair the thread.

[0004] For example, a patch file compiled using a dynamic link library contains a patch function func_a, and the patch function func_a contains a TLS variable t_flg. Then, the patch file compiled using the dynamic link library can usually be used to repair the thread with the vulnerability problem in the general dynamic mode (General Dynamic, GD). However, the prior art does not have a better solution to the failure of using the dynamic link library to repair. Summary of the invention

[0005] The embodiment of the present application provides a hot patch loading method and related devices, which can solve the problem that the second patch file cannot be repaired after the vulnerability function variable relocation fails during the dynamic linking process.

[0006] In a first aspect, an embodiment of the present application provides a hot patch loading method, the method comprising:

[0007] In the process of loading the first patch file in a dynamic linking manner based on the second patch file, after relocating the vulnerable function variable fails, compiling the second patch file in a static linking manner to determine the offset of the vulnerable function variable relative to the thread control block TCB pointer; wherein the first patch file is a vulnerability repair file, the second patch file is a vulnerability file, the second patch file is obtained by loading the target process, and the vulnerable function variable is obtained by parsing the second patch file; the type of the vulnerable function variable is a TLS variable type;

[0008] Using the offset and the preset offset adjustment, update the data in the address of the vulnerability function variable in the first patch file; wherein the address of the vulnerability function variable in the first patch file is determined by traversing the code included in the first patch file;

[0009] The second patch file is repaired according to the updated first patch file.

[0010] Compared with the prior art, in the dynamic linking process, after determining that the relocation of the vulnerable function variable has failed, the present application can compile the second patch file in a static linking manner, thereby determining the offset of the vulnerable function variable relative to the TCB pointer, and then update the first patch file by setting a preset offset adjustment amount and using the offset and the preset offset adjustment amount, so that the updated first patch file can accurately repair the vulnerability problem of the second patch file.

[0011] In a possible embodiment, whether the relocation of the vulnerable function variable fails is determined in the following manner:

[0012] Parsing the second patch file to obtain symbol table information of the vulnerable function variable; the symbol table information at least includes the name of the vulnerable function variable and the type of the vulnerable function variable;

[0013] When the type of the vulnerable function variable is a TLS variable type, based on the name of the vulnerable function variable, searching whether there is a same name of the vulnerable function variable in the relocation information obtained by relocating the vulnerable function variable in the second patch file;

[0014] If not found, it is determined that relocation of the vulnerable function variable has failed.

[0015] In the process of loading the first patch file in a dynamic linking manner based on the second patch file, the present application first obtains the symbol table information of the vulnerable function variable by parsing the second patch file, and then searches for the same variable name in the relocation message obtained by relocating the vulnerable function variable in the second patch file according to the name of the vulnerable function variable. If not found, it is determined that the relocation of the vulnerable function variable has failed, and it is necessary to use other methods to re-determine the offset so as to repair the vulnerability problem of the second patch file.

[0016] In a possible embodiment, the method further includes:

[0017] In the process of loading the first patch file in a dynamic linking manner based on the second patch file, if the relocation type representation of the vulnerable function variable requires relocation, relocating the vulnerable function variable;

[0018] After the relocation of the vulnerable function variable fails and before the second patch file is repaired according to the updated first patch file, the method further includes:

[0019] The relocation type of the vulnerable function variable is modified to a type indicating that relocation is not required.

[0020] The present application determines whether to relocate the vulnerable function variable by the relocation type of the vulnerable function variable. When the relocation of the vulnerable function variable fails during the dynamic linking process, the relocation type of the vulnerable function variable needs to be modified so as to determine the offset by static linking. After the first patch file is modified, when the first patch file is used to repair the vulnerability problem in the second patch file, the relocation fails again.

[0021] In a possible embodiment, compiling the second patch file in a static linking manner to determine the offset of the vulnerable function variable relative to the TCB pointer includes:

[0022] Compile the second patch file according to the static link mode, and parse the compiled second patch file to obtain symbol table information of the vulnerable function variable; the symbol table information at least includes the name of the vulnerable function variable and the offset of the vulnerable function variable relative to the TCB pointer;

[0023] According to the symbol table information of the vulnerable function variable and the name of the vulnerable function variable, the offset of the vulnerable function variable relative to the TCB pointer is determined.

[0024] The present application obtains symbol table information by parsing the second patch file compiled in a static linking manner, and then uses the symbol table information to determine the offset, and then updates the first patch file by the offset, so that the updated first patch file can repair the vulnerability problem of the second patch file.

[0025] In a possible embodiment, the updating of the data in the address of the vulnerable function variable in the first patch file by using the offset and the preset offset adjustment amount includes:

[0026] Adding the offset and the preset offset adjustment;

[0027] The data in the address of the vulnerable function variable in the first patch file is updated using the addition result.

[0028] The present application sets a preset offset adjustment amount, and adds the found offset and the preset offset adjustment amount, so that the data in the address of the vulnerable function variable in the first patch file is updated using the addition result, thereby accurately repairing the vulnerability problem in the second patch file.

[0029] In a second aspect, an embodiment of the present application provides a hot patch loading device, the device comprising:

[0030] The offset determination module is used for compiling the second patch file in a static linking manner to determine the offset of the vulnerability function variable relative to the thread control block TCB pointer after the relocation of the vulnerability function variable fails during the process of loading the first patch file in a dynamic linking manner based on the second patch file; wherein the first patch file is a vulnerability repair file, the second patch file is a vulnerability file, the second patch file is obtained by loading the target process, and the vulnerability function variable is obtained by parsing the second patch file; the type of the vulnerability function variable is a TLS variable type;

[0031] A data updating module, used to update the data in the address of the vulnerability function variable in the first patch file by using the offset and the preset offset adjustment; wherein the address of the vulnerability function variable in the first patch file is determined by traversing the code included in the first patch file;

[0032] The vulnerability repair module is used to repair the second patch file according to the updated first patch file.

[0033] In a possible embodiment, whether the relocation of the vulnerable function variable fails is determined in the following manner:

[0034] Parsing the second patch file to obtain symbol table information of the vulnerable function variable; the symbol table information at least includes the name of the vulnerable function variable and the type of the vulnerable function variable;

[0035] When the type of the vulnerable function variable is a TLS variable type, based on the name of the vulnerable function variable, searching whether the relocation information obtained by relocating the vulnerable function variable in the second patch file has the same name of the vulnerable function variable;

[0036] If not found, it is determined that relocation of the vulnerable function variable has failed.

[0037] In a possible embodiment, the device further includes:

[0038] In the process of dynamically linking the first patch file and the second patch file, if the relocation type representation of the vulnerable function variable indicates that relocation is required, relocating the vulnerable function variable;

[0039] The vulnerability repair module is also used to:

[0040] The relocation type of the vulnerable function variable is modified to a type indicating that relocation is not required.

[0041] In a possible embodiment, the offset determination module is specifically used to:

[0042] Compile the second patch file according to the static link mode, and parse the compiled second patch file to obtain symbol table information of the vulnerable function variable; the symbol table information at least includes the name of the vulnerable function variable and the offset of the vulnerable function variable relative to the TCB pointer;

[0043] According to the symbol table information of the vulnerable function variable and the name of the vulnerable function variable, the offset of the vulnerable function variable relative to the TCB pointer is determined.

[0044] In a possible embodiment, the data updating module is specifically used to:

[0045] Adding the offset and the preset offset adjustment;

[0046] The data in the address of the vulnerable function variable in the first patch file is updated using the addition result.

[0047] In a third aspect, an embodiment of the present application provides an electronic device, the device comprising:

[0048] At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute a method as described in any one of the first aspects.

[0049] In a fourth aspect, an embodiment of the present application provides a computer storage medium, wherein the computer storage medium stores a computer program, and the computer program is used to enable a computer to execute any method as described in the first aspect.

[0050] In a fifth aspect, an embodiment of the present application provides a computer program product, including a computer program / instructions, which, when executed by a processor, implements a method as described in any one of the first aspects.

[0051] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments of the present application will be briefly introduced below. Obviously, the drawings introduced below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0053] Figure 1A schematic diagram of the structure of multiple TLS variables and TCB pointers in a thread provided in an embodiment of the present application;

[0054] Figure 2 A schematic diagram of a process for accessing TLS variables using the GD mode provided in an embodiment of the present application;

[0055] Figure 3 A schematic diagram of a process for accessing TLS variables using the GD mode provided in an embodiment of the present application;

[0056] Figure 4 A schematic diagram of a process for determining whether relocation of a vulnerable function variable fails, provided in an embodiment of the present application;

[0057] Figure 5a A schematic diagram of a hot patch loading method provided in an embodiment of the present application;

[0058] Figure 5b A schematic diagram of a process for updating data in an address of a vulnerable function variable in a first patch file by using an offset and a preset offset adjustment amount provided in an embodiment of the present application;

[0059] Figure 6 A vulnerability function repair process provided in an embodiment of the present application;

[0060] Figure 7 A schematic diagram of the structure of a hot patch loading device provided in one embodiment of the present application;

[0061] Figure 8 A schematic diagram of an electronic device provided in one embodiment of the present application. DETAILED DESCRIPTION

[0062] In order to enable ordinary persons in the art to better understand the technical solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the accompanying drawings.

[0063] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present application described here can be implemented in an order other than those illustrated or described here. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. On the contrary, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the attached claims.

[0064] With the development of computer technology, software functions are constantly increasing. Vulnerabilities will inevitably appear during the operation of various software functions. Usually, restarting the device can solve the software vulnerability problem. Since the operation of some software functions cannot be interrupted, the hot patch technology can also be used to repair the software vulnerabilities without restarting the device. For example, the function with incorrect logic in the process operation is defined as the vulnerability function, and the function that repairs the vulnerability function is defined as the patch function. Since the function is called by instructions when the process is running, the instructions corresponding to the patch function can be replaced with the instructions corresponding to the vulnerability function to repair the vulnerability.

[0065] Each process can include one or more threads, and TLS is a thread-level storage mechanism. TLS allows each thread to have its own corresponding thread variables at runtime, and creates a separate access space for the variable. These variables can only be accessed by the corresponding thread and will not be accessed by other threads. For example, in an aarch64 type central processing unit (CPU), the address of the thread control block (TCB) pointer can be determined through the tpidr_el0 register, and then according to the address of the TCB pointer, the TCB pointer is offset to the address of the offset of TLS variable 1 relative to the TCB pointer. This address is the access space address of TLS variable 1 of thread 1 at runtime. By accessing the access space address, TLS variable 1 of thread 1 at runtime can be accessed.

[0066] like Figure 1 As shown, when the linker links, it is necessary to pre-arrange the access space address of the TLS variable and the address of the TCB pointer corresponding to each thread. Assume that thread 1 includes TLS variable 1, TLS variable 2, ..., TLS variable N and TCB pointer 1, and thread 2 includes TLS variable 1, TLS variable 2, ..., TLS variable M and TCB pointer 2. For thread 1, the offset of TLS variable 1 is 0, the offset of TLS variable 2 is 4, the offset of TLS variable N is 28, and the offset of TCB pointer is 32 (which can also be represented by 0x20). When TLS variable 1 is actually accessed, the address of TCB pointer 1 is determined to be 0x40020 through the tpidr_el0 register, and the offset of TLS variable 1 relative to the TCB pointer is 0–0x20=-0x20, so the access space address of TLS variable 1 is 0x40020-0x20=0x40000. By accessing the access space address 0x40000, TLS variable 1 can be accessed.

[0067] If a thread has a TLS variable and the thread has a vulnerability that needs to be repaired, the patch file compiled by the dynamic link library is usually used to repair the thread. For example, the patch file compiled by the dynamic link library contains a patch function func_a, and the patch function func_a contains the TLS variable t_flg. In this case, the patch file compiled by the dynamic link library can usually be used in GD mode to repair the thread with the vulnerability.

[0068] Next, we will introduce in detail how to use GD mode to access TLS variables.

[0069] First, in order to implement dynamic linking and delayed binding, such as Figure 2 As shown, step S201 is executed to pre-build the first corresponding relationship between the relocation information of the TLS variables of the thread and the offset of the TLS variables relative to the TCB pointer. For example, the offset of each TLS variable in the thread relative to the TCB pointer can be pre-stored in the global offset table (Global Offset Table, GOT). Procedure Linkage Table (PLT), the relocation information of each TLS variable can include the offset address of the corresponding TLS variable relative to the TCB pointer, and the first corresponding relationship can be determined according to the offset address of the corresponding TLS variable in the relocation information of the TLS variable relative to the TCB pointer in the GOT.PLT table. The offset of the corresponding TLS variable relative to the TCB pointer. The relocation information of each TLS variable can be determined by the first patch file responding to the relocation instruction during the process of loading the first patch file (also can be represented by the vulnerability repair file) in a dynamic linking mode. For example, the relocation instruction can be the readelf-Wr libhotpatchtest.so instruction.

[0070] The relocation information of each TLS variable may also include the relocation type of the corresponding TLS variable, wherein the relocation type of the TLS variable indicates that the TLS variable needs to be relocated during the dynamic linking process, as well as the specific operation process of the relocation. The relocation information of each TLS variable may also include the name of the corresponding TLS variable, where the offset address of the TLS variable relative to the TCB pointer-the relocation type of the TLS variable-the name of the TLS variable may be a one-to-one correspondence.

[0071] For example, the relocation information of multiple TLS variables is as follows, where offset represents the offset address of the TLS variable relative to the TCB pointer, type represents the relocation type of the TLS variable, and name represents the name of the TLS variable.

[0072] offset type name

[0073] 0000000000011008R_AARCH64_JUMP_SLOT sprintf@GLIBC_2.17

[0074] 0000000000011010R_AARCH64_JUMP_SLOT memset@GLIBC_2.17

[0075] 0000000000011018R_AARCH64_JUMP_SLOT__gmon_start__

[0076] 0000000000011020R_AARCH64_JUMP_SLOT mysym1

[0077] 0000000000011028R_AARCH64_JUMP_SLOT formatbuf

[0078] 0000000000011030R_AARCH64_JUMP_SLOT printf@GLIBC_2.17

[0079] 0000000000011058R_AARCH64_TLSDESC t_InSoflg3

[0080] 0000000000011048R_AARCH64_TLSDESC t_flgSum

[0081] 0000000000011078R_AARCH64_TLSDESC t_InSoflg2

[0082] 0000000000011068R_AARCH64_TLSDESC t_InSoflg

[0083] Among them, the relocation type of the TLS variable t_flgSum is R_AARCH64_TLSDESC, which indicates that the TLS variable t_flgSum needs to be relocated, and the offset address of the TLS variable t_flgSum relative to the TCB pointer is 0x0000000000011048; the relocation type of the TLS variable t_InSoflg2 is R_AARCH64_TLSDESC, which also indicates that the TLS variable t_InSoflg2 needs to be relocated, and the offset address of the TLS variable t_InSoflg2 relative to the TCB pointer is 0x0000000000011078.

[0084] Here, the dynamic link library libhotpatchtest.so may be parsed in the Executable and Linkable Format (ELF) format before responding to the relocation instruction. This is only an example, and the present application does not limit the specific parsing format of the dynamic link library.

[0085] After creating the first corresponding relationship, continue to execute step S202, by traversing the code of the first patch file compiled using the dynamic link library, obtain the offset of the target TLS variable relative to the TCB pointer. Then execute step S203, in the first corresponding relationship, find out whether there is an offset of the target TLS variable relative to the TCB pointer in the relocation information corresponding to different TLS variables and the offset of each TLS variable relative to the TCB pointer. If it exists, execute step S204, according to the first corresponding relationship, the offset of the target TLS variable relative to the TCB pointer-the relocation type of the target TLS variable-the name of the target TLS variable can be obtained. If it does not exist, execute step S206, end. It should be known here that the present application does not limit the specific execution order of step S201 and step S202.

[0086] After determining the offset of the target TLS variable relative to the TCB pointer, it is necessary to continue to execute step S205, determine the address of the TCB pointer in the thread through the register corresponding to the process where the thread with the vulnerability problem is located, and then access the TLS variable through the address of the TCB pointer and the offset of the target TLS variable relative to the TCB pointer, and the starting address of the code segment where the target TLS variable is located. Finally, the first patch file compiled with the offset of the target TLS variable in the dynamic link library relative to the TCB pointer and the address of the TCB pointer is used to repair the second patch file, wherein the second patch file is loaded based on the target process. For example, the first patch file can be a 24-byte binary assembly code compiled from the code for the operation of the TLS variable t_flgSum in GD mode, and the second patch file can be the code for the operation of the TLS variable t_flgSum.

[0087] Exemplarily, the following shows a portion of binary assembly code compiled according to the offset 0x11048 of the target TLS variable t_flgSum relative to the TCB pointer and the address of the TCB pointer:

[0088] 0x898:b0000080adrp x0,11000<__cxa_finalize@GLIBC_2.17>

[0089] 0x89c:f9402401ldr x1,[x0,#72]

[0090] 0x8a0:91012000add x0,x0,#0x48

[0091] 0x8a4:d63f0020 blr x1

[0092] 0x8a8:d53bd041 mrs x1,tpidr_el0

[0093] 0x8ac:8b000020add x0,x1,x0

[0094] In the first line of the above binary assembly code, at 0x898: b0000080adrp x0,11000<__cxa_finalize@GLIBC_2.17> indicates that 0x11000 is assigned to the x0 register. At this time, the value of the x0 register is 0x11000. In the second line, at 0x0x89c: f9402401ldr x1,[x0,#72] indicates that the value of the x0 register (0x11000) plus the data at 72 is loaded into the x1 register. At this time, the value of the x1 register is the data value at 0x11048 (0x11000+72=0x11048) in the GOT.PLT table. The third line at 0x8a0: 91012000add x0,x0,#0x48 means to add 0x48 to the value of the x0 register (0x11000) and assign it to the x0 register. At this time, the value of the x0 register is 0x11048 (0x11000+0x48=0x11048). The fourth line at 0x8a4: d63f0020 blr x1 means the instruction jumps to the value of the x1 register. The fifth line at 0x8a8: d53bd041 mrs x1,tpidr_el0 means to assign the address of the TCB pointer to the x1 register. At this time, the value of the x1 register is the address of the TCB pointer. At 0x8ac in the sixth line: 8b000020add x0,x1,x0 means adding the value of the x1 register to the value of the x0 register and assigning it to the x0 register. The value of the x0 register is the offset 0x11048 of the TLS variable relative to the TCB pointer, and the value of the x1 register is the address of the TCB pointer. The two are added together to get the TLS variable access space address, and the TLS variable access space address is reassigned to the x0 register. That is, at this time, the x0 register stores the access space address of the TLS variable t_flgSum. Access to the TLS variable t_flgSum can be achieved by accessing the x0 register.

[0095] For example, Figure 3As shown, firstly, step S301 is executed to traverse the code of the first patch file, and then step S302 is executed to determine whether the 4 bytes starting from the 16th byte store the code for operating the TCB pointer register tpidr_el0. Specifically, if the code segment at 0x8a8 of the fifth line above: d53bd041 mrs x1, tpidr_el0 exists in the code, it means that the continuous 24-byte code segment starting from 0x8a8 position 16 bytes forward (i.e. 0x898 position) is operating the TLS variable. If the result of the above step S302 is yes, step S303 is executed, and if the result of the above step S302 is no, step S308 is executed.

[0096] Step S303, extract the high-order part of the offset of the target TLS variable relative to the TCB pointer from the four-byte code segment starting from byte 0. Specifically, the code is offset 16 bytes forward at position 0x8a8 to obtain the code segment at 0x898 of the first line: b0000080adrp x0,11000. From the code segment at 0x898 of the first line, the high-order part 0x11000 of the offset of the target TLS variable relative to the TCB pointer can be obtained.

[0097] Step S304, extract the low-order part of the offset of the target TLS variable relative to the TCB pointer from the four-byte code segment starting from the 8th byte. Specifically, the code is offset 8 bytes forward at the position 0x8a8 to obtain the code segment at 0x8a0 of the third line above: 91012000add x0,x0,#0x48. From the code segment at 0x8a0 of the third line, the low-order part 0x0x48 of the offset of the target TLS variable relative to the TCB pointer can be obtained. Then continue to execute step S305, and the high-order part 0x11000 and the low-order part 0x0x48 of the offset of the target TLS variable relative to the TCB pointer are added to obtain the offset 0x11048 of the target TLS variable relative to the TCB pointer.

[0098] After obtaining the offset 0x11048 of the target TLS variable relative to the TCB pointer, continue to execute step S306, obtain relocation information by responding to the relocation instruction, and search in the relocation information whether there is the same target TLS variable with an offset of 0x11048 relative to the TCB pointer. If the result of the above step S306 is yes, execute step S307; if the result of the above step S306 is no, execute step S308.

[0099] Step S307, obtain the name of the target TLS variable (for example, the name is t_flgSum) and the starting address of the code segment where the target TLS variable is located (for example, the starting address is 0x898) through the search result. Step S308, end.

[0100] It should be noted that the above code segments and byte sizes are only examples, and the present application does not limit any specific code segments and specific byte sizes that can implement the solution of the present application.

[0101] Next, this application describes in detail how to use the Local Executable (LE) mode to access TLS variables.

[0102] LE mode can be compiled in a static link mode without dynamic loading and delayed binding. By parsing the second patch file compiled in a static link mode, the symbol table information of the TLS variable is obtained. The symbol table information of the TLS variable includes at least the offset of the TLS variable relative to the TCB pointer. For example, the offset of each TLS variable relative to the TCB pointer in the thread is pre-stored in the global offset table (Global Offset Table, GOT), and the symbol table information of the TLS variable may include the name of the TLS variable, the type of the corresponding TLS variable, the byte length occupied by the corresponding TLS variable, and the offset of the corresponding TLS variable relative to the TCB pointer, and the offset of the TLS variable relative to the TCB pointer-the type of the TLS variable-the name of the TLS variable-the byte length occupied by the TLS variable can be a one-to-one correspondence.

[0103] For example, the symbol table information of multiple TLS variables is as follows, where value represents the offset, the data stored in the offset is the offset of the TLS variable relative to the TCB pointer, size represents the byte length occupied by the TLS variable, type represents the type of the TLS variable, and name represents the name of the TLS variable.

[0104]

[0105]

[0106] For example, from the symbol table information of the above multiple TLS variables, it can be known that the offset of the TLS variable t_flgSum relative to the TCB pointer is 0x1018, and the TLS variable t_flgSum occupies a byte length of 4096. Further, it is also possible to determine whether the variable is a TLS variable by whether the type field in the symbol table information of the above multiple TLS variables is TLS.

[0107] Exemplarily, the following shows a portion of binary assembly code compiled according to the offset of the TLS variable t_flgSum relative to the TCB pointer and the address of the TCB pointer:

[0108]

[0109] In the first line 40115c of the above binary assembly code, the instruction 90000080adrp x0,411000<__FRAME_END__+0xf680> indicates that 0x411000 is assigned to the x0 register. At this time, the value of the x0 register is 0x411000. In the second line 401160, the instruction f947d400 ldr x0,[x0,#4008] indicates that the value of the x0 register (0x411000) plus 4008 is assigned to the data at 0x411FA8 to the x0 register. As shown in the figure below, 0x411FA8 is the offset of the TLS variable t_flgSum in the GOT table relative to the TCB pointer, and its value is 0x1028. After this instruction, the value of the x0 register is 0x1028, which is the offset of the TLS variable t_flgSum relative to the TCB pointer in the LE mode.

[0110] Disassembly of section.got:

[0111]

[0112]

[0113] Since the offset 0x1028 of the TLS variable t_flgSum in the GOT table relative to the TCB pointer and the offset 0x1018 of the TLS variable t_flgSum in LE mode relative to the TCB pointer are fixedly different by 0x10, and the difference 0x10 is a rule that exists in the access of each LE mode TLS variable, the offset relative to the TCB pointer obtained by accessing the TLS variable in the binary assembly code compiled in LE mode plus 0x10 can get the offset of the TLS variable t_flgSum in the GOT table relative to the TCB pointer.

[0114] The third line at 401164: d503201f nop does nothing, and the fourth line at 401168: d503201f nop does nothing either. These two lines do not perform any instruction operations just to make up the 24 bytes to access the TLS variable. The fifth line at 40116c: d53bd041 mrs x1,tpidr_el0 indicates that the address of the TCB pointer is assigned to the x1 register. At this time, the value of the x1 register is the address of the TCB pointer. At 401170 on the sixth line: 8b000020add x0,x1,x0 means adding the value of the x1 register to the value of the x0 register and assigning it to the x0 register. The value of the x0 register is the offset 0x1028 of the LE mode TLS variable relative to the TCB pointer, and the value of the x1 register is the address of the TCB pointer. The two are added together to get the TLS variable access space address, which is reassigned to the x0 register. That is, at this time, the x0 register stores the access space address of the TLS variable t_flgSum. Access to the TLS variable t_flgSum can be achieved by accessing the x0 register.

[0115] Usually, when the target TLS variable fails to be relocated in the process of loading the first patch file in a dynamic linking manner based on the second patch file, there is no other method to better repair the second patch file. After introducing the use of LE mode to access TLS variables, this application will now introduce in detail how to determine whether the relocation of the vulnerable function variable fails.

[0116] like Figure 4 As shown, first execute step S401, parse the second patch file, obtain the symbol table information of the vulnerable function variable, and then execute step S402 to determine whether the type of the vulnerable function variable in the symbol table information of the vulnerable function variable is a TLS variable type. If so, execute step S403, if not, execute step S405. Step S403, based on the name of the vulnerable function variable in the symbol table information of the vulnerable function variable, search whether there is the same name of the vulnerable function variable in the relocation information obtained by relocating the vulnerable function variable in the second patch file process, if not, execute step S404, if yes, execute step S405. Step S404, access the TLS variable according to the LE mode. Step S405, end.

[0117] Here, the specific execution process of steps S401 and S402 can refer to the introduction of accessing TLS variables in LE mode above, and the specific execution process of step S403 can refer to the introduction of accessing TLS variables in GD mode above, which will not be repeated here.

[0118] After determining that the relocation of the vulnerable function variable has failed, this application will next introduce in detail how to implement a solution for repairing the second patch file by adjusting the TLS variable access in LE mode.

[0119] like Figure 5a As shown, firstly, step S501 is executed. In the process of loading the first patch file in a dynamic linking manner based on the second patch file, after the relocation of the vulnerable function variable fails, the second patch file is compiled according to the static linking manner to determine the offset of the vulnerable function variable relative to the thread control block TCB pointer. And step S502, using the offset and the preset offset adjustment amount, the data in the address of the vulnerable function variable in the first patch file is updated; wherein the address of the vulnerable function variable in the first patch file is determined by traversing the code contained in the first patch file. Step S503, repair the second patch file according to the updated first patch file.

[0120] The specific execution process of step S501 can refer to the above introduction of accessing TLS variables in LE mode, which will not be repeated here.

[0121] Next, step S502 is described in detail: the offset and the preset offset adjustment are added, and the data in the address of the vulnerable function variable in the first patch file is updated according to the sum. Figure 5b As shown, first execute step S5021, replace the storage register of the offset in the assembly code compiled in static link mode with the storage register of the offset in the first patch file, and fill the replaced storage register with the sum of the offset and the preset offset adjustment amount; then execute step S5022, replace the storage register of the TCB pointer in the assembly code compiled in static link mode with the storage register of the TCB pointer in the first patch file; finally execute step S5023, replace the code of the vulnerable function variable at the starting address of the first patch file with the adjusted assembly code compiled in static link mode.

[0122] From the above GD mode and LE mode access to TLS variables, it can be seen that the length of the binary assembly code compiled by both can be 24 bytes. Exemplarily, the 24-byte assembly code for adjusting the GD mode access to TLS variables according to the LE mode access to TLS variables is as follows:

[0123]

[0124] The first line of the above binary assembly code at 400d88: 58000040ldr x0,#8<asm_jump_immw0b+0x8> The instruction indicates that the data at the position offset 8 bytes backward from the current position is loaded into the x0 register. The current position is offset 8 bytes backward, which is 400d90. The 8 consecutive bytes here are executed twice by the d503201f nop instruction without doing anything, just to fill up 24 bytes. If the value at 400d90 is modified to the 8-byte offset value of the relative TCB pointer obtained by accessing the TLS variable in LE mode, the offset value of the relative TCB pointer obtained by accessing the TLS variable in LE mode can be loaded into the x0 register. According to the first line of the assembly code for accessing the TLS variable in GD mode, b0000080adrp x0,11000<__cxa_finalize@GLIBC_2.17>, the register to be operated is extracted and replaced with the current x0 register (for example, if the GD mode operates the x1 register, then the x1 register is extracted to replace the current x0 register; if the GD mode operates the x0 register, then the current x0 register does not need to be replaced). That is, the offset value of the relative TCB pointer obtained by accessing the TLS variable in LE mode is loaded into register a of the offset value of the relative TCB pointer obtained by accessing the TLS variable in GD mode.

[0125] Second row at 400d8c: b 400d98 <skip>The instruction indicates an unconditional jump to 400d98, which is 8 bytes offset backward from the current position. In this way, the instructions in the third and fourth lines do not need to be executed. The continuous 8-byte space in the third and fourth lines is used to store the offset value of the relative TCB pointer obtained by accessing the TLS variable in LE mode. That is, the instructions at 400d90 in the third line: d503201f nop, and at 400d90 in the fourth line: d503201fnop do not perform any operation, and the offset value of the relative TCB pointer obtained by accessing the TLS variable in LE mode is filled in.

[0126] At 400d98 in the fifth line: the instruction d53bd040 mrs x0, tpidr_el0 indicates that the address of the TCB pointer is assigned to the x0 register. According to the assembly code for accessing TLS variables in GD mode, the fifth line d53bd041mrs x1, tpidr_el0 extracts the register for GD mode operation and replaces the x0 register, so that the address of the TCB pointer can be loaded into the register b that stores the TCB pointer address used to access TLS variables in GD mode.

[0127] At 400d9c in the sixth line: 8b000020add x0,x1,x0 means adding the value of the x0 register to the value of the x1 register and assigning it to the x0 register. The register a that stores the offset value of the relative TCB pointer obtained by accessing the TLS variable in GD mode replaces the x0 register, and the register b that stores the TCB pointer address replaces the x1 register. The register a used in the GD mode can be used to obtain the final access space address of the TLS variable.

[0128] After the above relocation fails, before repairing the second patch file by adjusting the access to the TLS variable in the LE mode, it is also necessary to modify the relocation type of the TLS variable in the updated first patch file to a type that does not require relocation, so as to avoid repair failure caused by relocation problems when repairing the second patch file using the updated first patch file. For example, the relocation type R_AARCH64_TLSDESC of the TLS variable t_flgSum in the relocation information in the GD mode is modified to R_AARCH64_JUMP_SLOT.

[0129] Next, step S503 is described in detail, which is a specific process of repairing the second patch file according to the updated first patch file:

[0130] Read the first vulnerable function where the vulnerable function variable is located in the updated first patch file, determine the second vulnerable function where the vulnerable function variable is located in the second patch file based on the first vulnerable function in the first patch file, and determine whether the function name of the first vulnerable function is the same as the function name of the second vulnerable function. If they are the same, modify the assembly instruction at the function address entry of the second vulnerable function so that the assembly instruction can jump to the function address of the first vulnerable function, thereby completing the vulnerability repair. Figure 6 As shown, func A is the first vulnerable function in the first patch file. Func A in the second patch file is determined through func A, and the assembly instruction at the function address entry of func A in the second patch file is modified to jump to the function address of func A.

[0131] Figure 7 A schematic diagram of the structure of a hot patch loading device provided in an embodiment of the present application is shown, and the device includes:

[0132] The offset determination module 701 is used for compiling the second patch file in a static linking manner to determine the offset of the vulnerability function variable relative to the thread control block TCB pointer after the relocation of the vulnerability function variable fails during the process of loading the first patch file in a dynamic linking manner based on the second patch file; wherein the first patch file is a vulnerability repair file, the second patch file is a vulnerability file, the second patch file is obtained by loading the target process, and the vulnerability function variable is obtained by parsing the second patch file; the type of the vulnerability function variable is a TLS variable type;

[0133] The data updating module 702 is used to update the data in the address of the vulnerable function variable in the first patch file by using the offset and the preset offset adjustment amount; wherein the address of the vulnerable function variable in the first patch file is determined by traversing the code included in the first patch file;

[0134] The vulnerability repair module 703 is used to repair the second patch file according to the updated first patch file.

[0135] In a possible embodiment, whether the relocation of the vulnerable function variable fails is determined in the following manner:

[0136] Parsing the second patch file to obtain symbol table information of the vulnerable function variable; the symbol table information at least includes the name of the vulnerable function variable and the type of the vulnerable function variable;

[0137] When the type of the vulnerable function variable is a TLS variable type, based on the name of the vulnerable function variable, searching whether the relocation information obtained by relocating the vulnerable function variable in the second patch file has the same name of the vulnerable function variable;

[0138] If not found, it is determined that the relocation of the vulnerable function variable has failed.

[0139] In a possible embodiment, the device further includes:

[0140] In the process of loading the first patch file in a dynamic linking manner based on the second patch file, if the relocation type representation of the vulnerable function variable indicates that relocation is required, relocating the vulnerable function variable;

[0141] The vulnerability repair module 703 is also used to:

[0142] Change the relocation type of the vulnerable function variable to a type that indicates that relocation is not required.

[0143] In a possible embodiment, the offset determination module 701 is specifically used for:

[0144] Compile the second patch file according to the static link mode, and parse the compiled second patch file to obtain symbol table information of the vulnerable function variable; the symbol table information at least includes the name of the vulnerable function variable and the offset of the vulnerable function variable relative to the TCB pointer;

[0145] The offset of the vulnerable function variable relative to the TCB pointer is determined according to the symbol table information of the vulnerable function variable and the name of the vulnerable function variable.

[0146] In a possible embodiment, the data updating module 702 is specifically configured to:

[0147] Adding the offset amount and the preset offset adjustment amount;

[0148] The data in the address of the vulnerable function variable in the first patch file is updated using the addition result.

[0149] After introducing the hot patch loading method and device according to an exemplary embodiment of the present application, next, an electronic device according to another exemplary embodiment of the present application is introduced.

[0150] Those skilled in the art will appreciate that various aspects of the present application may be implemented as a system, method or program product. Therefore, various aspects of the present application may be specifically implemented in the following forms, namely: a complete hardware implementation, a complete software implementation (including firmware, microcode, etc.), or a combination of hardware and software, which may be collectively referred to as "circuit", "module" or "system".

[0151] In some possible implementations, the electronic device according to the present application may include at least one processor and at least one memory. The memory stores program code, and when the program code is executed by the processor, the processor executes the steps in the hot patch loading method according to various exemplary embodiments of the present application described above in this specification. For example, the processor may execute the steps in the hot patch loading method.

[0152] Refer to the following Figure 8 The electronic device 80 according to this embodiment of the present application is described. Figure 8 The electronic device 80 shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0153] like Figure 8 As shown, the electronic device 80 is in the form of a general electronic device. The components of the electronic device 80 may include but are not limited to: at least one processor 81, at least one memory 82, and a bus 83 connecting different system components (including the memory 82 and the processor 81).

[0154] Bus 83 represents one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, and a processor or local bus using any of a variety of bus architectures.

[0155] The memory 82 may include a readable medium in the form of a volatile memory, such as a random access memory (RAM) 821 and / or a cache memory 822 , and may further include a read-only memory (ROM) 823 .

[0156] The memory 82 may also include a program / utility 825 having a set (at least one) of program modules 824, such program modules 824 including but not limited to: an operating system, one or more application programs, other program modules, and program data, each of which or some combination may include an implementation of a network environment.

[0157] The electronic device 80 may also communicate with one or more external devices 84 (e.g., keyboards, pointing devices, etc.), may also communicate with one or more devices that enable a user to interact with the electronic device 80, and / or may communicate with any device that enables the electronic device 80 to communicate with one or more other electronic devices (e.g., routers, modems, etc.). Such communication may be performed via an input / output (I / O) interface 85. Furthermore, the electronic device 80 may also communicate with one or more networks (e.g., local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) via a network adapter 86. As shown, the network adapter 86 communicates with other modules for the electronic device 80 via a bus 83. It should be understood that, although not shown in the figure, other hardware and / or software modules may be used in conjunction with the electronic device 80, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0158] In an exemplary embodiment, a computer-readable storage medium including instructions is also provided, such as a memory 82 including instructions, and the instructions can be executed by the processor 81 to perform the above method. Alternatively, the computer-readable storage medium can be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, etc.

[0159] In an exemplary embodiment, a computer program product is also provided, including a computer program / instruction, which, when executed by the processor 81, implements any of the hot patch loading methods provided in the present application.

[0160] In an exemplary embodiment, various aspects of a hot patch loading method provided by the present application can also be implemented in the form of a program product, which includes a program code. When the program product is run on a computer device, the program code is used to enable the computer device to execute the steps of a hot patch loading method according to various exemplary embodiments of the present application described above in this specification.

[0161] The program product may employ any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof.

[0162] The program product for unlocking an electronic device of the embodiment of the present application may adopt a portable compact disk read-only memory (CD-ROM) and include program code, and may be run on an electronic device. However, the program product of the present application is not limited thereto, and in this document, a readable storage medium may be any tangible medium containing or storing a program, which may be used by or in combination with an instruction execution system, apparatus, or device.

[0163] A readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, wherein readable program code is carried. Such propagated data signals may take a variety of forms, including, but not limited to, electromagnetic signals, optical signals, or any suitable combination of the foregoing. A readable signal medium may also be any readable medium other than a readable storage medium, which may transmit, propagate, or transfer a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0164] The program code embodied on the readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0165] The program code for performing the operation of the present application can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, C++, etc., and also conventional procedural programming languages ​​such as "C" language or similar programming languages. The program code can be executed entirely on the user electronic device, partially on the user device, as an independent software package, partially on the user electronic device and partially on the remote electronic device, or completely on the remote electronic device or server. In the case of a remote electronic device, the remote electronic device can be connected to the user electronic device through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external electronic device (for example, using an Internet service provider to connect through the Internet).

[0166] It should be noted that, although several units or subunits of the device are mentioned in the above detailed description, this division is merely exemplary and not mandatory. In fact, according to the embodiments of the present application, the features and functions of two or more units described above can be embodied in one unit. Conversely, the features and functions of one unit described above can be further divided into multiple units to be embodied.

[0167] In addition, although the operations of the method of the present application are described in a specific order in the drawings, this does not require or imply that the operations must be performed in this specific order, or that all the operations shown must be performed to achieve the desired results. Additionally or alternatively, some steps may be omitted, multiple steps may be combined into one step, and / or one step may be decomposed into multiple steps.

[0168] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented in one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0169] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable electronic device to generate a machine, so that the instructions executed by the processor of the computer or other programmable electronic device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0170] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable electronic device to work in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0171] These computer program instructions may also be loaded onto a computer or other programmable electronic device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for executing on the computer or other programmable device to implement the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0172] Although the preferred embodiments of the present application have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications falling within the scope of the present application.

[0173] Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these modifications and variations.< / skip>

Claims

1. A hot patch loading method, characterized in that: The method comprises: In the process of loading the first patch file in a dynamic linking manner based on the second patch file, after relocating the vulnerable function variable fails, compiling the second patch file in a static linking manner to determine the offset of the vulnerable function variable relative to the thread control block TCB pointer; wherein the first patch file is a vulnerability repair file, the second patch file is a vulnerability file, the second patch file is obtained by loading the target process, and the vulnerable function variable is obtained by parsing the second patch file; the type of the vulnerable function variable is a TLS variable type; Using the offset and the preset offset adjustment, update the data in the address of the vulnerability function variable in the first patch file; wherein the address of the vulnerability function variable in the first patch file is determined by traversing the code included in the first patch file; The second patch file is repaired according to the updated first patch file.

2. The method according to claim 1, characterized in that: Determine whether the relocation of the vulnerable function variable fails by the following methods: Parsing the second patch file to obtain symbol table information of the vulnerable function variable; the symbol table information at least includes the name of the vulnerable function variable and the type of the vulnerable function variable; When the type of the vulnerable function variable is a TLS variable type, based on the name of the vulnerable function variable, searching whether the relocation information obtained by relocating the vulnerable function variable in the second patch file has the same name of the vulnerable function variable; If not found, it is determined that relocation of the vulnerable function variable has failed.

3. The method according to claim 1, characterized in that: The method further comprises: In the process of loading the first patch file in a dynamic linking manner based on the second patch file, if the relocation type representation of the vulnerable function variable requires relocation, relocating the vulnerable function variable; After the relocation of the vulnerable function variable fails and before the second patch file is repaired according to the updated first patch file, the method further includes: The relocation type of the vulnerable function variable is modified to a type indicating that relocation is not required.

4. The method according to claim 1, characterized in that Compiling the second patch file in a static linking manner to determine the offset of the vulnerable function variable relative to the TCB pointer includes: Compile the second patch file according to the static link mode, and parse the compiled second patch file to obtain symbol table information of the vulnerable function variable; the symbol table information at least includes the name of the vulnerable function variable and the offset of the vulnerable function variable relative to the TCB pointer; According to the symbol table information of the vulnerable function variable and the name of the vulnerable function variable, the offset of the vulnerable function variable relative to the TCB pointer is determined.

5. The method according to claim 1, characterized in that: The updating of the data in the address of the vulnerability function variable in the first patch file by using the offset and the preset offset adjustment amount includes: Adding the offset and the preset offset adjustment; The data in the address of the vulnerable function variable in the first patch file is updated using the addition result.

6. A thermal patch loading device, characterized in that: The device comprises: The offset determination module is used for compiling the second patch file in a static linking manner to determine the offset of the vulnerability function variable relative to the thread control block TCB pointer after the relocation of the vulnerability function variable fails during the process of loading the first patch file in a dynamic linking manner based on the second patch file; wherein the first patch file is a vulnerability repair file, the second patch file is a vulnerability file, the second patch file is obtained by loading the target process, and the vulnerability function variable is obtained by parsing the second patch file; the type of the vulnerability function variable is a TLS variable type; A data updating module, used to update the data in the address of the vulnerability function variable in the first patch file by using the offset and the preset offset adjustment; wherein the address of the vulnerability function variable in the first patch file is determined by traversing the code included in the first patch file; The vulnerability repair module is used to repair the second patch file according to the updated first patch file.

7. The device according to claim 6, characterized in that Determine whether the relocation of the vulnerable function variable fails by the following methods: Parsing the second patch file to obtain symbol table information of the vulnerable function variable; the symbol table information at least includes the name of the vulnerable function variable and the type of the vulnerable function variable; When the type of the vulnerable function variable is a TLS variable type, based on the name of the vulnerable function variable, searching whether there is a same name of the vulnerable function variable in the relocation information obtained by relocating the vulnerable function variable in the second patch file; If not found, it is determined that relocation of the vulnerable function variable has failed.

8. The device according to claim 6, characterized in that The device also includes: In the process of loading the first patch file in a dynamic linking manner based on the second patch file, if the relocation type representation of the vulnerable function variable requires relocation, relocating the vulnerable function variable; The vulnerability repair module is also used to: The relocation type of the vulnerable function variable is modified to a type indicating that relocation is not required.

9. An electronic device, characterized in that: The device comprises: At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor so that the at least one processor can execute the method as claimed in any one of claims 1 to 5.

10. A computer storage medium, characterized in that: The computer storage medium stores a computer program, and the computer program is used to enable a computer to execute the method according to any one of claims 1 to 5.

Images