A method for dynamic extension and hot patching of kernel data types based on alignment holes

Abstract

The present invention discloses a kernel data type extension hot patching method based on aligned holes, comprising: S1, pre-processing a patch file to extract valid information of a hot patch object; S2, analyzing the internal hole layout of the hot patch target data type according to the description file of the input data type update operation extracted in step S1, and outputting a type layout definition; S3, combining the description file of the data type update operation outputted in step S1 and the new type definition outputted by the hole layout analysis outputted in step S2, writing a hot patch module program to generate a hot patch module; S4, installation and effectiveness of the hot patch module: installing the hot patch module generated in step S3 to the kernel and waiting for the update point to make the patch content effective, completing the hot patch update task. The present invention can utilize the empty space inside the data object member, reduce the management tasks responsible for the extended space and the rewriting of the access method, and reduce the burden of hot patch development.

Description

Technical Field

[0001] The present invention relates to the technical field of dynamic update of operating system kernels, and in particular to a kernel data type expansion hot patching method based on alignment holes. Background Art

[0002] The operating system kernel needs patches to fix vulnerabilities, optimize performance, and add new features. The traditional patch update method requires restarting the device to replace the kernel, which leads to interruption of system services, causing many inconveniences and even huge losses. The dynamic update and hot patching technology of the operating system kernel can complete the patch task without machine downtime and restart scenarios.

[0003] The kernel patch update task includes replacing kernel functions and changing data types. By using the kernel's reserved insertion points in the function header, the kernel can complete the change of the function execution flow at the update point. However, when it comes to data type changes, the current mainstream hot patching system still lacks an efficient solution to solve the space problem of type extension. This is because the existing technology needs to manage the external space of object type extensions, and maintaining the dependency relationship brought by the extension causes additional operating overhead in accessing and managing the extension members. Summary of the invention

[0004] The present invention aims at the common scenario of data type expansion demand in kernel patch, solves the space problem of member expansion by analyzing and finding holes in the layout of hot patch objects, and completes the work of converting the patch into a hot patch module by modifying the corresponding kernel function according to the expansion mode, and provides a low-overhead kernel data type dynamic expansion hot patch method. By utilizing the correlation between holes and hot patch data objects, the use of updated data types is realized by type forced conversion to reduce the operation overhead. By utilizing the correlation between holes and data objects, a method of updating data views by forced type conversion is designed, which ensures efficient access to extended members while retaining the original data so that other functions are not affected by update and replacement, which greatly reduces the additional execution overhead after data hot patching. On the one hand, the data acquisition method through member access is retained, and on the other hand, the allocation, release and access control of the parent object by the inheritance kernel do not require additional management operations. By managing extended members by means of allocation and release of data objects, it is avoided to modify the kernel functions responsible for initialization and release, which helps developers reduce additional manual burden.

[0005] To achieve the above object, the present invention adopts the following technical solutions:

[0006] A kernel data type expansion hot patching method based on alignment holes, the hot patching method comprising the following steps:

[0007] S1, pre-process the patch file and extract the effective information of the hot patch object:

[0008] Filter out the contents irrelevant to hot patching and affecting the hot patching mechanism from the patch file, extract the patch update information, divide the patch update information into data type update operations and corresponding function replacement operations, and form a corresponding description file;

[0009] S2, according to the description file of the input data type update operation extracted in step S1, analyze the internal hole layout of the hot-patch target data type, and output the type layout definition:

[0010] Enumerate the structure name to be updated according to the description file, query the symbol table information provided in the kernel image and parse the debug information to calculate the internal space layout of the hot patch object, and convert it into a description and location of the hole; analyze the space size of the extended member to match the hole space, and then form an updated data type view by marking the version of the hole and setting the access mode bit;

[0011] S3, combining the description file of the data type update operation output by step S1 and the new type definition output by the hole layout analysis output by step S2, compiling a hot patch module program to generate a hot patch module; the compiling process includes: modifying the access method of the function that uses the new member after the type update, retranslating the layout information of the original data object by pointer type conversion, and completing the initialization and access operation of the new member by base address offset; combining the metadata tag formed after the hole analysis inside the object to select different access modes; adding semantic judgment to the initialization of the hot patch module to ensure that the execution order of the initialization operation precedes the access, and providing a public interface for developers to access and an open file system interface for system user interaction;

[0012] S4, installation and validation of the hot patch module: the hot patch module generated in step S3 is installed into the kernel and waits for the update point to make the patch content take effect, thus completing the hot patch update task.

[0013] To optimize the above technical solutions, the specific measures taken also include:

[0014] Furthermore, in step S1, the process of preprocessing the patch file and extracting effective information of the hot patch object includes the following steps:

[0015] Step 21, input the patch file, compare the differences of a single file, decompose the patch file into multiple target files and record the path of each target file;

[0016] Step 22, determining whether the target files are code contents irrelevant to the current hot patch one by one, if they are irrelevant contents, proceed to step 2B, otherwise proceed to step 23;

[0017] Step 23, matching is performed through the rule base illegal_rules to determine whether the matching path involves update operations related to plugging and determination of resident functions; if the match is successful, proceed to step 2B, otherwise proceed to step 24;

[0018] Step 24, determine the type of the modified object, if it is a type definition, proceed to step 25, if it is a function modification, proceed to step 27;

[0019] Step 25, decompose the steps of the type definition according to the operations of adding, replacing and deleting members in the type definition. The record format is (op, main_type, sub_type, sub_name), where op represents the addition, deletion or update of the data type, main_type represents the modified parent data type body, sub_type represents the modified member type, and sub_name is the member name;

[0020] Step 26, merge the decomposed operations into the array of type_ops objects in the type operation set patch_report.json; go to step 2A;

[0021] Step 27, determine whether it is a modification of a macro or a static function, if so, proceed to step 28, otherwise proceed to step 29;

[0022] Step 28, manually adjusting the expansion of the macro used in the corresponding function and the redefinition of the static function in the calling function to form a semantically equivalent adjustment;

[0023] Step 29, merge the non-type modifications in the patch into the array of func_ops objects in patch_report.json;

[0024] Step 2A, optimize and merge the patch content to form a complete patch_report.json report;

[0025] Step 2B, determine whether the patch file has been processed to the end, if yes, go to step 2C, otherwise go to step 22;

[0026] Step 2C: output the type update operation description set and the function update operation set, and record the differentiated file name paths.

[0027] Further, in step S2, according to the description file of the input data type update operation extracted in step S1, the internal hole layout of the hot-patch target data type is analyzed, and the output type layout definition includes the following steps:

[0028] Step 31, extract the type name main_type from the data type operation set type_ops of the patch preprocessing output patch_report.json and assign it to type_name;

[0029] Step 32, read the information in the .debuginfo area of ​​the kernel image VMLINUX compiled with CONFIG_DEBUG_INFO enabled, the format of which is DWARF;

[0030] Step 33, matching the first-level type name in the DWARF format information to be equal to type_name;

[0031] Step 34, traverse all members under the first-level type in turn, determine their data_member_location and size, and determine the hole size by calculating hole_size=next_location-(size+cur_location). The hole location is hole_location=size+cur_location;

[0032] Step 35, determine whether the child members are completely traversed, if yes, go to step 36, otherwise go back to step 34;

[0033] Step 36, record the calculation results hole_size and hole_location in step 34 into holes_map, with main_type as the key name and the dictionary group holes as the value;

[0034] Step 37, get the sub-member sub_type of the current entry of the object in the type operation type_ops, and determine its type name and size;

[0035] Step 38, allocate space for the extended member in combination with the hole layout description holes_map to form a new data type definition output;

[0036] Step 39, determine whether the entries in the type operation set type_ops object are completely traversed, if yes, proceed to step 3A, otherwise return to step 31;

[0037] Step 3A, end the process.

[0038] Furthermore, in step 38, the process of allocating space for the extended member in combination with the hole layout description holes_map to form a new data type definition output includes the following steps:

[0039] Step 41, input the original object type name main_name and the extended member name member_name and type member_type;

[0040] Step 42, query the original type name hole layout description hash table holes_map, and use the original object type main_type as the key to query the hash table to obtain the holes layout description;

[0041] Step 43, traverse holes, determine whether the continuous holes meet the size requirement of type allocation, if sizeof(sub_type)<=hole_size, it is determined that the size requirement of type allocation is met, and go to step 44, otherwise go to step 46;

[0042] Step 44, set the mode mark bit mode in the metadata in the hole to 0. The metadata uses the 1B space in the first holes in the hole layout of the original object and is excluded from the hole space for mode marking and version record. Mode = 0 indicates that in-site mode access is used, that is, direct access mode.

[0043] Step 45, assigning the continuous hole as the initial offset address of the new member, and updating the used hole information from holes_map;

[0044] Step 46, setting the mode bit to 1, mode = 1 indicates using out-site access, that is, indirect access mode;

[0045] Step 47, determine whether there is a single hole that satisfies the size of the pointer space 8B, if yes, proceed to step 48, otherwise proceed to step 49;

[0046] Step 48, record the current hole offset position offset as member_location, and generate a new member record (add, main_type, member_type, member_name, member_location) in the main_type description; go to step 4B;

[0047] Step 49, determine whether there are two 4B-sized holes, if yes, proceed to step 4A, otherwise proceed to step 4B;

[0048] Step 4A, by setting two 4B holes in main_type, setting them to p_low and p_high of type u32 as members of the splicing pointer, and recording this operation in the description of main_type;

[0049] Step 4B, forming a new data type definition based on the offset position of the newly added member record mark, named main_type_v1, and outputting this type definition as the target type for subsequent forced type conversion;

[0050] Step 4C, end the process.

[0051] Furthermore, in step S3, in combination with the description file of the data type update operation outputted in step S1 and the new type definition outputted by the hole layout analysis outputted in step S2, the process of writing the hot patch module program to generate the hot patch module includes the following steps:

[0052] Step 51, input the header file containing the new type definition and the function update operation set func_ops;

[0053] Step 52, determine whether the current function operation involves the use of a new member, if so, proceed to step 53, otherwise proceed to step 5A;

[0054] Step 53, perform type forced conversion on the data object, and the conversion target is the new data type main-_type_v1 defined in the header file;

[0055] Step 54, determine whether the mode bit in metadata is 0, if yes, proceed to step 55, otherwise proceed to step 56;

[0056] Step 55, directly use the member access symbol to modify the function update content; go to step 59;

[0057] Step 56, set the initialization and space allocation release function of the member, and record the allocated address as sub_addr;

[0058] Step 57, add a W_COMBINEADDR macro in the initialization function to set p_low to the lower 32 bits of sub_addr, and p_high to the upper 32 bits of sub_addr, and call the initialization and allocation release functions in the allocation function of the parent object;

[0059] Step 58, in the access operation involving the new member in the current function, add R_COMBINEADDR to dereference the member pointer;

[0060] Step 59, forming a modified function definition and renaming it to [func_name]_dlp, providing input for the subsequent stub replacement operation;

[0061] Step 5A, determine whether the function set traversal is completed, if yes, proceed to step 5B, otherwise proceed to step 52;

[0062] Step 5B, in response to the function setting stub and the symbol problem that comes with it, dynamically change the execution logic through function replacement;

[0063] Step 5C, setting the order in the linked list through ftrace to define the insertion order of the update function and registering the hot patch version information through the programming interface dlp_register to set the initialization state of the hot patch;

[0064] Step 5D, write Makefile and Kconfig files to form module compilation conditions, and enter make -C / lib / modules / `uname -r` / build M=`pwd` in the command line terminal to generate the target module file hotpatch.ko;

[0065] Step 5E, end the process.

[0066] Furthermore, in step 5B, in view of the function setting stub and the symbol problem caused thereby, the process of dynamically changing the execution logic through function replacement includes the following steps:

[0067] Step 61, input the function operation set func_ops;

[0068] Step 62, by judging whether the function parameter contains the parent object type main_type, to judge whether the type leads to the modification of the function prototype, if yes, go to step 65, otherwise go to step 63;

[0069] Step 63, determining whether the kernel symbol set encountered during the function use process is a kernel export symbol, if yes, proceeding to step 64, otherwise, proceeding to step 66;

[0070] Step 64, determine the address of the exported symbol in the kernel by calling kallsyms_lookup_name();

[0071] Step 65, using the function through a function pointer, assigning a target function prototype to the function pointer to indirectly call the target function through the function pointer;

[0072] Step 66, modify the calling logic to form an updated function definition [func_name]_dlp;

[0073] Step 67, querying the symbol information through the .debuginfo information in VMLINUX to confirm whether the function is optimized to an inline function, if yes, proceed to step 68, otherwise proceed to step 69;

[0074] Step 68, find all callers of the inline function in the kernel source code, and replace the inline function with the updated call of [func_name]_dlp;

[0075] Step 69, using the ftrace stub mechanism to replace the original function [func_name], the replacement target is [func_name]_dlp, and the klp_register_patch function provided by the kernel livepatch mechanism is used. The replacement of the original function is completed by setting the original function and the target function;

[0076] Step 6A, determine whether the function update operation set is traversed, if yes, go to step 6B, otherwise go back to step 62;

[0077] Step 6B, end the process.

[0078] Furthermore, in step S4, the process of installing and taking effect of the hot patch module includes the following steps:

[0079] Step 81, input the hotpatch module file hotpatch.ko outputted in step 5D;

[0080] Step 82: Enter sudo insmod hotpatch.ko in the command line terminal to install the hotpatch module in the kernel.

[0081] Step 83, executing the initialization action set in step 5C, responsible for replacing static global variables, pre-allocating variable space required for indirect access mode, and additional operations required for hot patching tasks;

[0082] Step 84, set the hot patch state of the target thread, set patch_state to 1 to start hot patching;

[0083] Step 85, based on the unwind stack backtracking, check whether the target function exists in the kernel stack at the current moment. If not, it indicates that it is a safe update point, and go to step 86, otherwise go back to step 84;

[0084] Step 86, based on ftrace, the function replacement operation is performed, and the original function insertion point is replaced by binary, and the execution flow is changed to the target update function;

[0085] Step 87, set the patch_state of the current thread to 0, and the hot patching process ends;

[0086] Step 88, register the current hot patch version information through the register interface;

[0087] Step 89, end the process.

[0088] The beneficial effects of the present invention are:

[0089] First, the kernel data type expansion hot patching method based on alignment holes of the present invention effectively supports the common demand for data type expansion in kernel patches and broadens the application scope of the hot patching technology.

[0090] Secondly, the kernel data type extension hot patching method based on aligned holes of the present invention utilizes the hole space inside the data object member, reduces the management tasks responsible for the extension space and the rewriting of the access method, and alleviates the burden of hot patch development.

[0091] Third, the kernel data type expansion hot patching method based on aligned holes of the present invention effectively utilizes the existing cache based on the internal holes of the object, which is faster than reading the external space, and efficient hits will reduce access latency. BRIEF DESCRIPTION OF THE DRAWINGS

[0092] Figure 1 This is a flowchart of a kernel data type expansion method based on alignment holes according to an embodiment of the present invention.

[0093] Figure 2 is a flowchart of patch preprocessing according to an embodiment of the present invention

[0094] Figure 3 is a flow chart of hole layout analysis according to an embodiment of the present invention

[0095] Figure 4 This is a flow chart of extended member matching according to an embodiment of the present invention.

[0096] Figure 5 It is a flow chart generated by the hot patch module in an embodiment of the present invention.

[0097] Figure 6 It is a flowchart of symbol resolution and instrumentation in a function update operation in an embodiment of the present invention.

[0098] Figure 7 It is a definition diagram for a user interaction interface and a programming interface according to an embodiment of the present invention.

[0099] Figure 8 It is an operation flow chart of the installation and validation of the hot patch module according to an embodiment of the present invention. DETAILED DESCRIPTION

[0100] The present invention will now be described in further detail with reference to the accompanying drawings.

[0101] It should be noted that the terms such as "upper", "lower", "left", "right", "front", "back", etc. cited in the invention are only for the convenience of description and are not used to limit the scope of implementation of the present invention. Changes or adjustments in their relative relationships should be regarded as the scope of implementation of the present invention without substantially changing the technical content.

[0102] Based on the characteristic that internal holes are generated when objects are allocated space according to the compilation alignment requirements, this embodiment provides a kernel data type extension hot patching method based on alignment holes. The hot patching method includes the following key operations:

[0103] S1, patch preprocessing. Preprocess the patch file, extract the patch update information from the patch file, and filter out its non-hot patch security operations. Input the patch file and output the filtered and optimized patch content. The output of this operation will be used as the input part of step S2 hole layout analysis and step S3 hot patch module generation. The specific operations can be divided into: first filter out the content that is not related to hot patching, including comments and documents, and then exclude the parts that will affect the update security of the hot patch mechanism, including modifications to the plug-in dependency mechanism, and finally extract data type updates and function changes. The data type update part is recorded as a description of the type update operation, and then the update description and function changes of the patch are output.

[0104] S2, analysis of hole layout. According to the target information extracted by the patch information extraction operation, analyze the internal hole layout of the hot-patch target data type. Input the description of the type operation after the patch preprocessing operation in step S1, and output the type layout definition. This output will be used as the input for the generation of the hot-patch module in step S3. The specific operations are as follows: enumerate the structure names to be updated according to the description file, calculate the internal spatial layout of the hot-patch object by querying the symbol table information provided in the kernel image and parsing the debugging information, and convert it into a description and location of the hole. Analyze the spatial size of the extended member to match the hole space, and then form an updated data type view by marking the version of the hole and setting the access mode bit.

[0105] S3, generation of hot patch module. Combining the update operation description generated by the patch preprocessing in step S1 and the new type definition output by the hole layout analysis in S2, a hot patch module program is written to generate a hot patch module. This involves the modification of related functions and the positioning of target object symbols. After forming a new data type view, the related kernel functions need to be modified to change the way they access data. Two modes, direct access and pointer indirect access, are designed to expand the scenario coverage of type hot patching.

[0106] S4, installation and validation of hot patch module. It is used to install the module generated in step S3 into the kernel and wait for the update point to make the patch content take effect, completing the hot patch update task. It can be specifically divided into module installation, module initialization, hot patch initial state setting update point waiting and hot patch taking effect, hot patch completion state setting and version registration.

[0107] like Figure 1 As shown in the workflow diagram of the kernel data type extension method based on alignment holes, this embodiment proposes a kernel data type extension hot patching method based on alignment holes, which is used for dynamic update tasks involving data type extension in kernel patches, and is described in actual operation based on the Linux kernel under the x86_64 architecture. It generally includes four types of operations, namely, patch preprocessing, hole layout analysis, hot patch module generation, and hot patch module installation and effectiveness.

[0108] The patch preprocessing operation is to extract the effective information of the hot patch object, which will provide the input of the update content for the subsequent hole layout analysis and hot patch module generation. The patch preprocessing includes filtering irrelevant content, optimizing patch implementation and extracting update operations. The hot patch work is simplified by filtering irrelevant content to avoid interference with the generation of the hot patch module, and at the same time, some update operations that will make the hot patch unsafe are eliminated to ensure the reliability of the hot patch method. Optimizing patch implementation is to filter optimization operations that are irrelevant to the hot patch function, and to expand the definition of kernel macros involved in the update to optimize the effectiveness of the hot patch. The extraction of update content is performed after filtering irrelevant content and optimizing patches. The update content is divided into update operations of data types and corresponding function replacement operations, and a description file is formed to guide the hole layout analysis and the generation of hot patch modules.

[0109] The hole layout analysis operation is to solve the problem of extended space encountered in type updates. When generating hot patch modules, it is considered that extended members need additional memory space to be placed. It is specifically divided into hole layout generation and extended member matching to be responsible for updating content and hole matching. The generation of hole layout information is to analyze the memory layout of members of the hot patch data type through the debugging information of the kernel image, and to provide space information for the subsequent matching of extended members. The matching of extended members is the use of holes in data types, and the application of holes is completed by generating type definitions compatible with the original data layout view. At the same time, all modified kernel functions are marked for subsequent hot patch module generation.

[0110] The hot patch module generation operation is to write the module in combination with the current kernel version and complete the compilation and generation of the hot patch module. It is mainly responsible for the replacement of related functions in the update, the positioning of symbols in the kernel and the setting of initialization operations. Related functions refer to functions that use new members after type updates, and need to modify their access methods. The layout information of the original data object is retranslated through pointer type conversion, and the initialization and access operations of the new members are completed through base address offset. Symbol positioning is to solve the problem of symbols that the kernel has not exported to developers. It is mainly used to solve the use of static global variables and internal static functions involved in function updates. After solving the problems of function update and symbol positioning, in order to ensure that data will not be uninitialized and cause access exceptions, it is necessary to add semantic judgment to the initialization of the module in the module generation stage to ensure that the execution order of the initialization operation precedes the access. At the same time, it provides a public interface for developers to access and an open file system interface for system user interaction.

[0111] The installation and validation of the hotpatch module utilizes the compiled hotpatch module, relying on the dynamic loading feature of the module as the implementation carrier for the dynamic update of the kernel data type. The hotpatch module is installed through insmod, the pre-set initialization action is executed, and the existing kernel mechanism livepatch is called to check the update point to complete the function replacement. Finally, the hotpatch version is recorded through the registration interface to complete the hotpatch update task.

[0112] Figure 2 This is the patch preprocessing flow chart. The security of hot patching is not only the security of the hot patching process, but also includes the security of compilation and operation when the hot patching module is generated. The correctness of the official patch will be guaranteed by the submitter through unit testing and the reviewer's inspection, which can be completed from the lexical, grammatical and semantic inspection tools and unit testing framework. However, since the patch can only guarantee the security of the source code and does not consider the application of the hot patching scenario, there will actually be content in the patch that conflicts with the hot patching mechanism, so it needs to be screened and inspected. The filter will preprocess the officially released patches, and its purpose is to ensure that the hot patch will be in line with the correctness of the dynamic update of the kernel. The most important feature is that the hot patch cannot modify the functions related to the ftrace itself, the instrumentation mechanism based on the function update, and the functions involved in the resident kernel thread. In addition, we extract the basic content of the patch through preprocessing, and output the changes in functions and data types in json format to guide the subsequent generation of hot patch modules. We will filter it through the script tool, and then manually remove the optimized code with unchanged semantics. The process is implemented as follows Figure 2 As shown, we need to add regular matching items to the filter rule library to optimize the output. The patch that passes the filter will generate a report, record the modified functions and data types, and output streamlined code. The specific process is as follows:

[0113] Step 20, start the process.

[0114] Step 21, input the patch file. A single diff entry in the patch file represents the differential comparison of a single file. We decompose it into processing units by matching the keyword "diff--git" and record the target file path.

[0115] Step 22, through regular matching, determine whether it is a code comment, kernel configuration, and whether it contains the keyword __init__ kernel initialization code. Determine whether it is assembly code and kernel documentation through the suffix of the path file name. And determine whether the path under arch is code content that is irrelevant to the current platform; if it is irrelevant content, go to step 2B, otherwise go to step 23.

[0116] Step 23, whether the matching path involves kprobe, ftrace, alternative and other plug-in related and resident function judgment update operations, matching is performed through the rule base illegal_rules. If the matching result is yes, go to step 2B, otherwise go to step 24.

[0117] Step 24, determine the modification object by matching the string after the second "@@" in each line with grep, and use the keyword "struct" to confirm that it is a data type modification. If it is a type definition, go to step 25, otherwise go to step 27.

[0118] Step 25, decompose the steps of the type definition according to the operations of adding, replacing and deleting members in the type definition. The record format is (op, main_type, sub_type, sub_name). Among them, op represents the addition, deletion or update of the data type, main_type represents the modified parent data type body, sub_type represents the modified member type, and sub_name is the member name.

[0119] Note that the positions of the members are not specified here, because the internal position adjustment of the members during the structure definition phase does not affect the reading of the data.

[0120] Step 26: merge the decomposed operations into the array of type_ops objects in the type operation set patch_report.json. Go to step 2A.

[0121] Step 27, determine whether it is a modification of a macro or a static function, and distinguish by matching the keywords define and static. If yes, proceed to step 28, otherwise proceed to step 29.

[0122] Step 28, by manually adjusting the expansion of the macro used in the corresponding function and the redefinition of the static function in the calling function, a semantically equivalent adjustment is formed.

[0123] Step 29, merge the non-type modifications in the patch into the array of func_ops objects in patch_report.json.

[0124] Step 2A, by adjusting the implementation in step 26 and step 29, exclude some optimization operations that are not related to the hot patch target, and function replacement behaviors that can be merged, optimize the content and merge it to form a complete patch_report.json report.

[0125] Step 2B, determine whether the patch file has been processed to the end, if so, go to step 2C, otherwise there are other differences that need to be processed and go to step 22.

[0126] Step 2C: Output patch_report.json that records the type update operation type_ops and the function update operation func_ops, and also records the differentiated file name paths, providing input for subsequent hole layout analysis and hot patch module generation.

[0127] Step 2D, end the process.

[0128] Figure 3 This is a flow chart for hole layout analysis. Hot patching needs to resolve the association between extended members and parent objects, and the existence of structure types is to describe the collection of data of the same or different types, and to establish the connection between them through a continuous physical storage structure. For the case where the memory of existing objects is fixed, it is observed that the alignment technology at compile time will produce holes inside the data object, and holes are used to meet the expansion requirements of data types. Here we will explain how to calculate the compiled holes to form the hole layout information of the hot patch object and the matching of extended members and hole layouts. This is the preparation for the generation of the hot patch module, which will form a new data type layout definition header file new_type_vx.h. The specific process is as follows:

[0129] Step 30, start the process;

[0130] Step 31: extract the type name main_type from the data type operation set type_ops of the patch preprocessing output patch_report.json and assign it to type_name.

[0131] Step 32, read the information in the .debuginfo area in the kernel image VMLINUX compiled with CONFIG_DEBUG_INFO enabled, the format of which is DWARF.

[0132] Step 33, matching the first-level type name name in the DWARF format information to be equal to type_name.

[0133] Step 34, analyze the holes between members, traverse all members under the first-level type in turn, determine their data_member_location and size, and determine the hole size by calculating hole_size=next_location-(size+cur_location). The hole location is hole_location=size+cur_location;

[0134] Step 35, determine whether the child members are completely traversed, if so, go to step 36, otherwise return to step 34.

[0135] Step 36, record the calculation results hole_size and hole_location in step 34 into holes_map, with main_type as the key name and the dictionary group holes as the value.

[0136] Step 37, get the sub-member sub_type of the current entry of the object in the type operation type_ops, and determine its type name and size.

[0137] Step 38, matching of the extended space, is used to allocate space for the extended members in combination with the hole layout description holes_map, and then form a new data type definition output. For detailed step decomposition, see Figure 4 .

[0138] Step 39, determine whether the entries in the type operation set type_ops object are completely traversed, if so, go to step 3A, otherwise return to step 31.

[0139] Step 3A, end the process.

[0140] Figure 4 To expand the member matching flow chart, the layout information and update operation will be combined to allocate holes to the data object to form a new data layout definition. For ease of use, the present invention will force the translation of internal member offset information through type conversion. This provides input for the modification of related call functions in the subsequent generation of hot patch modules. The specific process is as follows:

[0141] Step 40, start the process.

[0142] Step 41, input the original object type name main_name and the extended member name member_name and type member_type.

[0143] They are assigned values ​​for main_type, sub_name and sub_type respectively.

[0144] Step 42, query the original type name hole layout description hash table holes_map, and use the original object type main_type as the key to query the hash table to obtain the holes layout description.

[0145] Step 43, traverse holes, and determine whether the continuous holes meet the size requirement of type allocation. If sizeof(sub_type)<=hole_size, then go to step 44, otherwise go to step 46.

[0146] Step 44, set the mode mark bit mode in the metadata in the hole to 0. The metadata uses the 1B space in the first holes in the hole layout of the original object and is excluded from the hole space for mode marking and version record. Mode = 0 indicates that in-site mode access is used, that is, direct access mode.

[0147] Step 45: Allocate the continuous hole as the initial offset address of the new member, and update the used hole information from holes_map. Go to step 4B.

[0148] Step 46, setting the mode bit to 1, mode=1 indicates using out-site access, that is, indirect access mode.

[0149] Step 47, determine whether there is a single hole that satisfies the size of the pointer space 8B, if so, proceed to step 48, otherwise proceed to step 49.

[0150] Step 48, record the current hole offset position offset as member_location, and generate a new member record (add, main_type, member_type, member_name, member_location) in the main_type description; go to step 4B.

[0151] Step 49, determine whether there are two 4B-sized holes, if so, proceed to step 4A, otherwise proceed to step 4B.

[0152] Step 4A, by setting two 4B holes in main_type, set them to p_low and p_high of type u32 as members of the splicing pointer, which is the call to the modified COMBINEADDR macro in the subsequent function. Then record this operation in the description of main_type, which is consistent with step 48.

[0153] Step 4B, forming a new data type definition based on the offset position of the newly added member record mark in the above step, named main_type_v1, and outputting this type definition as the target type for subsequent forced type conversion.

[0154] Step 4C, end the process.

[0155] Figure 5 Flowchart generated for the hotpatch module. After obtaining the new type definition after allocating in combination with the hole, we need to modify the usage function for this type in the original patch. It is necessary to select different access modes based on the metadata tags formed after the hole analysis inside the object, then set the initialization steps and compile and output the hotpatch module in combination with the kernel source code, and finally form a kernel module that completes the dynamic update. The specific process is as follows:

[0156] Step 50, start the process.

[0157] Step 51, input a header file containing a new type definition and a function update operation set func_ops.

[0158] Step 52, use the string matching sub_name for the current function update operation, if the match is successful, go to step 53, otherwise go to step 5A.

[0159] Step 53, perform type forced conversion on the data object, and the conversion target is the new data type main_type_v1 defined in the header file.

[0160] Step 54, determine whether the mode bit in metadata is 0, if yes, go to step 55, otherwise go to step 56.

[0161] Step 55: directly use the member access symbol to modify the function update content. Go to step 59.

[0162] Step 56, set the initialization and space allocation release function of the member, and record the allocated address as sub_addr.

[0163] Step 57, add a W_COMBINEADDR macro in the initialization function to set p_low to the lower 32 bits of sub_addr and p_high to the upper 32 bits of sub_addr. The initialization and allocation release functions are called in the allocation function of the parent object.

[0164] Step 58, in the access operation involving the new member in the current function, add R_COMBINEADDR to dereference the combined pointer to access the member.

[0165] Step 59, generate the updated function definition and rename it to [func_name]_dlp to provide input for the subsequent stub replacement operation.

[0166] Step 5A, determine whether the function set traversal is completed, if so, go to step 5B, otherwise go to step 52.

[0167] Step 5B, set up instrumentation for the function and solve the symbol problem that comes with it, and dynamically change the execution logic through function replacement. This part is in Figure 6 This will be explained in detail.

[0168] Step 5C, perform initialization settings for the module, define the insertion order of the update function by setting the order in the linked list through ftrace, register the hot patch version information through the programming interface dlp_register, and set the initialization state of the hot patch.

[0169] Step 5D, write Makefile and Kconfig files to form module compilation conditions, and then enter make -C / lib / modules / `uname -r` / build M = `pwd` in the command line terminal to generate the target module file hotpatch.ko.

[0170] Step 5E, end the process.

[0171] Figure 6 This is a flowchart for symbol resolution and instrumentation in function update operations. It is used to resolve the modification of function prototypes and the resolution of unexported symbols after type updates. The specific process is as follows:

[0172] Step 60, start the process.

[0173] Step 61, input the function operation set func_ops.

[0174] Step 62, determine whether the type leads to modification of the function prototype, the determination method is to determine whether the function parameter contains the parent object type main_type. If yes, proceed to step 65, otherwise proceed to step 63.

[0175] Step 63, determine whether the kernel symbol set encountered during the function use process is a kernel export symbol, that is, exported by the EXPORT series macro in the kernel source code. If yes, proceed to step 64, otherwise proceed to step 66.

[0176] Step 64, determine the address of the exported symbol in the kernel by calling kallsyms_lookup_name().

[0177] Step 65, using the function through a function pointer, and assigning a target function prototype to the function pointer to indirectly call the target function.

[0178] Step 66, modify the calling logic to form an updated function definition [func_name]_dlp.

[0179] Step 67, determine whether the function is optimized to an inline function, that is, query the symbol information through the .debuginfo information in VMLINUX to confirm whether it is inlined. If yes, proceed to step 68, otherwise proceed to step 69.

[0180] Step 68, search the kernel source code for all callers of the inline function, perform replacements within the set, and replace the inline function with the updated call to [func_name]_dlp.

[0181] Step 69, using the ftrace stub mechanism to replace the original function [func_name], the replacement target is [func_name]_dlp, and the klp_register_patch function provided by the kernel livepatch mechanism is used. The replacement of the original function is completed by setting the original function and the target function.

[0182] Step 6A, determine whether the function update operation set is traversed completely, if so, proceed to step 6B, otherwise return to step 62.

[0183] Step 6B, end the process.

[0184] Figure 7 Define graphs for user interaction interface and programming interface. Used to define programming interface and user interaction interface. UM (Update Manager) is the kernel module provided by this method for programming implementation. It is used to provide version control interface and support programming interface for cumulative update operation. Register is used to register the version of this hot patch when the hot patch is completed. Query is used to query the latest version of the current hot patch during the initialization phase. Update is used to update the registration information of the current version. Cancellation is used to cancel the current version when rolling back the updated version. In addition, in order to facilitate real-time control by users, the path / sysfs / dlp / type / version / inspection is opened under sysfs based on the kernel livepatch mechanism to view the status and version information of the current type of hot patch. In the command line terminal, echo 0> / sysfs / dlp / type / version / on to perform the rollback operation.

[0185] Figure 8This is a flowchart for the installation and validation of the hotpatch module. It is used to install the hotpatch module into the kernel, mark the hotpatch status and complete the hotpatch update task. The specific steps are as follows:

[0186] Step 80, start the process.

[0187] Step 81, input the hotpatch module file hotpatch.ko outputted in step 5D.

[0188] Step 82: Enter sudo insmod hotpatch.ko in the command line terminal to install the hotpatch module in the kernel.

[0189] Step 83, module initialization, will execute the initialization action set in step 5C, which is responsible for replacing static global variables, pre-allocating variable space required for indirect access mode, and additional operations required for hot patching tasks.

[0190] Step 84, setting the hot patch state of the target thread, and setting patch_state to 1 indicates starting the hot patch.

[0191] Step 85, based on the unwind stack backtracking, check whether the target function exists in the kernel stack at the current moment. If not, it indicates that it is a safe update point and proceeds to step 86, otherwise it returns to step 84.

[0192] Step 86, based on ftrace, a function replacement operation is performed, a binary replacement is performed at the original function insertion point, and the execution flow is changed to the target update function.

[0193] Step 87, setting the patch_state of the current thread to 0, indicating that the hot patching process is finished.

[0194] Step 88, register the current hot patch version information through the register interface.

[0195] Step 89, end the process.

[0196] The above are only preferred embodiments of the present invention, and the protection scope of the present invention is not limited to the above embodiments. All technical solutions under the concept of the present invention belong to the protection scope of the present invention. It should be pointed out that for ordinary technicians in this technical field, some improvements and modifications without departing from the principle of the present invention should be regarded as the protection scope of the present invention.

Claims

1. A kernel data type extension hot patching method based on alignment holes, It is characterized in that The hot patching method comprises the following steps: S1, pre-process the patch file and extract the effective information of the hot patch object: Filter out the contents irrelevant to hot patching and affecting the hot patching mechanism from the patch file, extract the patch update information, divide the patch update information into data type update operations and corresponding function replacement operations, and form a corresponding description file; S2, according to the description file of the input data type update operation extracted in step S1, analyze the internal hole layout of the hot-patch target data type, and output the type layout definition: Enumerate the structure name to be updated according to the description file, query the symbol table information provided in the kernel image and parse the debug information to calculate the internal space layout of the hot patch object, and convert it into a description and location of the hole; analyze the space size of the extended member to match the hole space, and then form an updated data type view by marking the version of the hole and setting the access mode bit; S3, combining the description file of the data type update operation output by step S1 and the new type definition output by the hole layout analysis output by step S2, compiling a hot patch module program to generate a hot patch module; the compiling process includes: modifying the access method of the function that uses the new member after the type update, retranslating the layout information of the original data object by pointer type conversion, and completing the initialization and access operation of the new member by base address offset; combining the metadata tag formed after the hole analysis inside the object to select different access modes; adding semantic judgment to the initialization of the hot patch module to ensure that the execution order of the initialization operation precedes the access, and providing a public interface for developers to access and an open file system interface for system user interaction; S4, installation and validation of the hot patch module: installing the hot patch module generated in step S3 into the kernel and waiting for the update point to make the patch content take effect, thus completing the hot patch update task; In step S1, the process of preprocessing the patch file and extracting the effective information of the hot patch object includes the following steps: Step 21, input the patch file, compare the differences of a single file, decompose the patch file into multiple target files and record the path of each target file; Step 22, determining whether the target files are code contents irrelevant to the current hot patch one by one, if they are irrelevant contents, proceed to step 2B, otherwise proceed to step 23; Step 23, matching is performed through the rule base illegal_rules to determine whether the matching path involves update operations related to plugging and determination of resident functions; if the match is successful, proceed to step 2B, otherwise proceed to step 24; Step 24, determine the type of the modified object, if it is a type definition, proceed to step 25, if it is a function modification, proceed to step 27; Step 25, decomposing the steps of the type definition according to the operations of adding, replacing and deleting members in the type definition; the record format is (op, main_type, sub_type, sub_name), where op represents the addition, deletion or update of the data type, main_type represents the modified parent data type body, sub_type represents the modified member type, and sub_name is the member name; Step 26, merge the decomposed operations into the array of type_ops objects in the type operation set patch_report.json; go to step 2A; Step 27, determine whether it is a modification of a macro or a static function, if so, proceed to step 28, otherwise proceed to step 29; Step 28, manually adjusting the expansion of the macro used in the corresponding function and the redefinition of the static function in the calling function to form a semantically equivalent adjustment; Step 29, merge the non-type modifications in the patch into the array of func_ops objects in patch_report.json; Step 2A, optimize and merge the patch content to form a complete patch_report.json report; Step 2B, determine whether the patch file has been processed to the end, if yes, go to step 2C, otherwise go to step 22; Step 2C: output the type update operation description set and the function update operation set, and record the differentiated file name paths.

2. The kernel data type expansion hot patching method based on alignment holes according to claim 1, It is characterized in that In step S2, according to the description file of the input data type update operation extracted in step S1, the internal hole layout of the hot-patch target data type is analyzed, and the output type layout definition includes the following steps: Step 31, extract the type name main_type from the data type operation set type_ops of the patch preprocessing output patch_report.json and assign it to type_name; Step 32, read the information in the .debuginfo area of ​​the kernel image VMLINUX compiled with CONFIG_DEBUG_INFO enabled, the format of which is DWARF; Step 33, matching the first-level type name in the DWARF format information to be equal to type_name; Step 34, traverse all members under the first-level type in turn, determine their data_member_location and size, and determine the hole size by calculating hole_size=next_location-(size+cur_location). The hole location is hole_location=size+cur_location; Step 35, determine whether the child members are completely traversed, if yes, go to step 36, otherwise go back to step 34; Step 36, record the calculation results hole_size and hole_location in step 34 into holes_map, with main_type as the key name and the dictionary group holes as the value; Step 37, get the sub-member sub_type of the current entry of the object in the type operation type_ops, and determine its type name and size; Step 38, allocate space for the extended member in combination with the hole layout description holes_map to form a new data type definition output; Step 39, determine whether the entries in the type operation set type_ops object are completely traversed, if yes, proceed to step 3A, otherwise return to step 31; Step 3A, end the process.

3. The kernel data type expansion hot patching method based on alignment holes according to claim 2, It is characterized in that In step 38, the process of allocating space for the extended member in combination with the hole layout description holes_map to form a new data type definition output includes the following steps: Step 41, input the original object type name main_name and the extended member name member_name and type member_type; Step 42, query the original type name hole layout description hash table holes_map, and use the original object type main_type as the key to query the hash table to obtain the holes layout description; Step 43, traverse holes, determine whether the continuous holes meet the size requirement of type allocation, if sizeof(sub_type)<=hole_size, it is determined that the size requirement of type allocation is met, and go to step 44, otherwise go to step 46; Step 44, set the mode mark bit mode in the metadata in the hole to 0. The metadata uses the 1B space in the first holes in the hole layout of the original object and is excluded from the hole space for mode marking and version record. Mode = 0 indicates that in-site mode access is used, that is, direct access mode. Step 45, assigning the continuous hole as the initial offset address of the new member, and updating the used hole information from holes_map; Step 46, setting the mode bit to 1, mode = 1 indicates using out-site access, that is, indirect access mode; Step 47, determine whether there is a single hole that satisfies the size of the pointer space 8B, if yes, proceed to step 48, otherwise proceed to step 49; Step 48, record the current hole offset position offset as member_location, and generate a new member record (add, main_type, member_type, member_name, member_location) in the main_type description; go to step 4B; Step 49, determine whether there are two 4B-sized holes, if yes, proceed to step 4A, otherwise proceed to step 4B; Step 4A, by setting two 4B holes in main_type, setting them to p_low and p_high of type u32 as members of the splicing pointer, and recording this operation in the description of main_type; Step 4B, forming a new data type definition based on the offset position of the newly added member record mark, named main_type_v1, and outputting this type definition as the target type for subsequent forced type conversion; Step 4C, end the process.

4. The kernel data type expansion hot patching method based on alignment holes according to claim 1, It is characterized in that In step S3, the process of writing a hot patch module program to generate a hot patch module in combination with the description file of the data type update operation outputted in step S1 and the new type definition outputted by the hole layout analysis outputted in step S2 includes the following steps: Step 51, input the header file containing the new type definition and the function update operation set func_ops; Step 52, determine whether the current function operation involves the use of a new member, if so, proceed to step 53, otherwise proceed to step 5A; Step 53, perform type forced conversion on the data object, and the conversion target is the new data type main-_type_v1 defined in the header file; Step 54, determine whether the mode bit in metadata is 0, if yes, proceed to step 55, otherwise proceed to step 56; Step 55, directly use the member access symbol to modify the function update content; go to step 59; Step 56, set the initialization and space allocation release function of the member, and record the allocated address as sub_addr; Step 57, add a W_COMBINEADDR macro in the initialization function to set p_low to the lower 32 bits of sub_addr, and p_high to the upper 32 bits of sub_addr, and call the initialization and allocation release functions in the allocation function of the parent object; Step 58, in the access operation involving the new member in the current function, add R_COMBINEADDR to dereference the member pointer; Step 59, forming a modified function definition and renaming it to [func_name]_dlp, providing input for the subsequent stub replacement operation; Step 5A, determine whether the function set traversal is completed, if yes, proceed to step 5B, otherwise proceed to step 52; Step 5B, in response to the function setting stub and the symbol problem that comes with it, dynamically change the execution logic through function replacement; Step 5C, setting the order in the linked list through ftrace to define the insertion order of the update function and registering the hot patch version information through the programming interface dlp_register to set the initialization state of the hot patch; Step 5D, write Makefile and Kconfig files to form module compilation conditions, and enter make -C / lib / modules / `uname -r` / build M = `pwd` in the command line terminal to generate the target module file hotpatch.ko; Step 5E, end the process.

5. The kernel data type expansion hot patching method based on alignment holes according to claim 4, It is characterized in that In step 5B, in order to solve the instrumentation problem of the function and the symbol problem caused by it, the process of dynamically changing the execution logic through function replacement includes the following steps: Step 61, input the function operation set func_ops; Step 62, by judging whether the function parameter contains the parent object type main_type, to judge whether the type leads to the modification of the function prototype, if yes, go to step 65, otherwise go to step 63; Step 63, determining whether the kernel symbol set encountered during the function use process is a kernel export symbol, if yes, proceeding to step 64, otherwise, proceeding to step 66; Step 64, determine the address of the exported symbol in the kernel by calling kallsyms_lookup_name(); Step 65, using the function through a function pointer, assigning a target function prototype to the function pointer to indirectly call the target function through the function pointer; Step 66, modify the calling logic to form an updated function definition [func_name]_dlp; Step 67, querying the symbol information through the .debuginfo information in VMLINUX to confirm whether the function is optimized to an inline function, if yes, proceed to step 68, otherwise proceed to step 69; Step 68, find all callers of the inline function in the kernel source code, and replace the inline function with the updated call of [func_name]_dlp; Step 69, using the ftrace stub mechanism to replace the original function [func_name], the replacement target is [func_name]_dlp, and the klp_register_patch function provided by the kernel livepatch mechanism is used. The replacement of the original function is completed by setting the original function and the target function; Step 6A, determine whether the function update operation set is traversed, if yes, go to step 6B, otherwise go back to step 62; Step 6B, end the process.

6. The kernel data type expansion hot patching method based on alignment holes according to claim 4, It is characterized in that In step S4, the process of installing and taking effect of the hot patch module includes the following steps: Step 81, input the hotpatch module file hotpatch.ko outputted in step 5D; Step 82: Enter sudo insmod hotpatch.ko in the command line terminal to install the hotpatch module in the kernel. Step 83, executing the initialization action set in step 5C, responsible for replacing static global variables, pre-allocating variable space required for indirect access mode, and additional operations required for hot patching tasks; Step 84, set the hot patch state of the target thread, set patch_state to 1 to start hot patching; Step 85, based on the unwind stack backtracking, check whether the target function exists in the kernel stack at the current moment. If not, it indicates that it is a safe update point, and go to step 86, otherwise go back to step 84; Step 86, based on ftrace, the function replacement operation is performed, and the original function insertion point is replaced by binary, and the execution flow is changed to the target update function; Step 87, set the patch_state of the current thread to 0, and the hot patching process ends; Step 88, register the current hot patch version information through the register interface; Step 89, end the process.

Images