Kernel patch manufacturing method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention provides a kernel patch manufacturing method and device, electronic equipment and a storage medium, and the method comprises the steps: obtaining patch manufacturing configuration information which comprises a compiling mode, a length threshold value of a kernel symbol and a version identifier of a target kernel; determining a to-be-compiled file list according to the compiling mode; reading kernel native symbols from the kernel executable file according to the length threshold of the kernel symbols and constructing a native symbol list; compiling each source file in the to-be-compiled file list according to the native symbol list to correspondingly obtain each target file; and linking each target file to obtain a linked file, and adding the version identifier of the target kernel to the linked file to obtain a patch of the target kernel. The limitation of strict consistency of kernel versions can be broken through, the deployment flexibility is improved, and the application range is widened; the long symbol analysis bottleneck is eliminated, and the compatibility and robustness of the patch are enhanced; an intelligent compiling mode is introduced, so that the development and debugging efficiency is greatly improved.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a kernel patching method, apparatus, electronic device and storage medium. Background Technology

[0002] With the rapid development of the cloud computing industry, the pace of hardware technology iteration has accelerated significantly. For example, central processing units (CPUs) typically see a new generation of products every 1-2 years, and storage devices such as memory and hard drives follow a similar product cycle. In contrast, server operating systems in cloud computing scenarios usually have a longer update cycle, with major version updates occurring only every 3-5 years on average. This mismatch between the iteration speed of hardware and software often leads to problems when deploying older versions of operating systems on new-generation hardware devices, such as the operating system's inability to effectively recognize or fully utilize the features of the new hardware.

[0003] To address the aforementioned issues, current methods typically employ hot patching to dynamically repair the running operating system kernel, adapting it to new hardware and avoiding service interruptions caused by system reboots. However, in developing this invention, the inventors discovered the following problems with existing hot patching technologies in practical applications:

[0004] First, the requirement for kernel version consistency is too strict, which greatly limits the applicability and deployment flexibility of hot patches.

[0005] Second, there are limitations in the ability to resolve the length of kernel function symbol names, which can easily lead to loading failures.

[0006] Third, the lack of breakpoint resume capability leads to low development and debugging efficiency. Summary of the Invention

[0007] This invention provides a kernel patching method, apparatus, electronic device, and storage medium that can overcome the strict consistency requirement of kernel versions, improve deployment flexibility and applicability; eliminate long symbol parsing bottlenecks, enhance patch compatibility and robustness; and introduce an intelligent compilation mode, significantly improving development and debugging efficiency.

[0008] In a first aspect, the kernel patch creation method provided in the embodiments of the present invention includes:

[0009] Obtain patch creation configuration information, which includes compilation mode, kernel symbol length threshold, and target kernel version identifier;

[0010] Determine the list of files to be compiled based on the compilation mode;

[0011] Kernel native symbols are read from the kernel executable file according to the length threshold of the kernel symbols, and a list of native symbols is constructed based on the kernel native symbols;

[0012] The source files in the list of files to be compiled are compiled according to the native symbol list to obtain the corresponding target files;

[0013] The target files are linked together to obtain a linked file, and the version identifier of the target kernel is added to the linked file to obtain a patch for the target kernel.

[0014] Secondly, the kernel patch creation apparatus provided in this embodiment of the invention includes:

[0015] The acquisition module is used to acquire patch creation configuration information, which includes compilation mode, kernel symbol length threshold and target kernel version identifier;

[0016] The determination module is used to determine the list of files to be compiled based on the compilation mode.

[0017] The reading module is used to read kernel native symbols from the kernel executable file according to the length threshold of the kernel symbols, and to construct a list of native symbols based on the kernel native symbols;

[0018] The compilation module is used to compile each source file in the list of files to be compiled according to the native symbol list, so as to obtain each target file.

[0019] The linking module is used to link the various target files to obtain a linked file, and to add the version identifier of the target kernel to the linked file to obtain a patch for the target kernel.

[0020] Thirdly, the electronic device provided in the embodiments of the present invention includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the kernel patch making method as described in any embodiment of the present invention.

[0021] Fourthly, the computer-readable storage medium provided in the embodiments of the present invention stores a computer program thereon, which, when executed by a processor, implements the kernel patch making method as described in any embodiment of the present invention.

[0022] In this embodiment of the invention, the "target kernel version identifier" configuration information is introduced. When generating a patch, the kernel version is actively marked, ensuring that the patch can be accepted by the target kernel loader and decoupling the compilation environment from the runtime environment. Even if the kernel executable version used during compilation differs from the kernel version currently running in the system, as long as the core interfaces are compatible, the generated hot patch can be verified by the version identifier and successfully loaded, breaking the rigid constraints of existing technologies. Operations personnel no longer need to maintain a complete compilation environment and high-precision kernel executable for each minor kernel version; they can more flexibly choose available compilation bases, significantly reducing the complexity and cost of environment maintenance, making it possible to batch create and distribute patches for a large number of different minor kernel versions. Through the "kernel symbol length threshold" configuration, the symbol resolution length is dynamically adjusted, enabling the complete reading and parsing of extremely long function names and complex symbols that may appear in modern kernels, avoiding reference or loading errors caused by symbol truncation. The "compile mode" configuration allows users to choose according to different scenarios and flexibly adopt different compilation modes. For example, when "incremental compilation" is configured, it can automatically identify and recompile only the source files that have changed, reuse the existing compilation results, and after fixing a minor error, there is no need to go through a long full compilation wait, which greatly shortens the compilation time and improves development and debugging efficiency. Attached Figure Description

[0023] To more clearly illustrate the technical solution of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 This is a flowchart illustrating a kernel patch creation method provided in an embodiment of the present invention;

[0025] Figure 2 This is another flowchart illustrating the kernel patch creation method provided in this embodiment of the invention;

[0026] Figure 3 This is an example diagram of the kernel patch creation method provided in an embodiment of the present invention;

[0027] Figure 4 This is a schematic diagram of a kernel patch creation apparatus provided in an embodiment of the present invention;

[0028] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0029] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0030] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0031] Figure 1 This is a schematic flowchart of a kernel patch creation method provided in an embodiment of the present invention. The kernel patch creation method provided in this embodiment is applicable to scenarios involving the creation of hot patches for the operating system kernel. This kernel patch creation method can be executed by a kernel patch creation device provided in this embodiment, which can be implemented in software and / or hardware. In a specific embodiment, the device can be integrated into an electronic device, such as a tablet computer, personal computer, or computer, and the electronic device has a kernel hot patch creation tool installed. The following embodiment uses the integration of the kernel patch creation device into an electronic device as an example for illustration. See also... Figure 1 The kernel patch creation method in this embodiment may include the following steps:

[0032] Step 101: Obtain patch creation configuration information, which includes compilation mode, kernel symbol length threshold, and target kernel version identifier.

[0033] Patch creation configuration information is a set of parameters or instructions provided by the user when executing the hot patch creation command. It tells the hot patch creation tool (such as kpatch) how to perform the compilation and patch generation tasks. Traditional hot patch creation tools have fixed behavior. This invention introduces this configurable information set to make the tool's behavior flexible and adaptable to complex scenarios.

[0034] Compilation mode is a parameter used to control the compilation strategy. It defines how the tool handles the conversion process from source code to binary files. Compilation modes can include full compilation and incremental compilation. Full compilation reprocesses everything; the tool cleans up all previous intermediate compilation results and compiles each source file from scratch. This mode ensures an absolutely clean compilation environment and is suitable for initial compilations or creating fully reliable release versions. Incremental compilation only processes the changed parts. The tool intelligently analyzes which source files have been modified (or their dependencies have changed) since the last compilation and only recompiles those files, while directly reusing the other unchanged compilation results. This mode greatly improves efficiency during the development and debugging phases and enables resume compilation from breakpoints.

[0035] The kernel symbol length threshold is a numerical parameter that specifies the maximum number of bytes allowed for a symbol name. This threshold tells tools to expand their internal symbol name buffer to at least accommodate names of this length, enabling tools to fully read and parse all long symbols in modern kernels and resolving compatibility issues caused by technical limitations.

[0036] The target kernel version identifier is a string that specifies which specific version of the operating system kernel the generated hot patch is ultimately intended to run on. The user actively provides the target kernel version identifier. The tool can write this identifier into the patch's metadata at the end of the patch file generation process. When the patch is loaded, the system loader checks this written identifier; if it matches the currently running kernel version (or is allowed under compatibility rules), it can be loaded. This makes it possible to create patches for running kernel version B from kernel version A, greatly expanding the applicability of the patches.

[0037] When the kernel hot patch creation tool starts executing, it first receives and parses a set of user-defined control parameters. These parameters explicitly include three key instructions: how to compile (i.e., incremental or full compilation), how to prepare the compilation environment (i.e., the size of the symbol name buffer), and for which kernel (i.e., which kernel version this patch will ultimately be applied to). Through these three configurations—compilation mode, kernel symbol length threshold, and target kernel version identifier—the traditional fixed and rigid hot patch generation process is transformed into a highly parameterized, customizable, and target-environment-oriented intelligent process.

[0038] Step 102: Determine the list of files to be compiled based on the compilation mode.

[0039] The list of files to be compiled is a collection of source file paths. It is a specific list of tasks that need to be performed during the compilation phase, and it determines the workload and content of subsequent compilation steps.

[0040] The kernel hot patching tool automatically generates a list of source files to be processed by the compiler based on the user-specified compilation mode (full or incremental). This is achieved through a built-in intelligent analysis logic. For full compilation, the tool scans the entire patch project's source code directory, collecting the paths of all identified source files to form a list of files to be compiled. Full compilation ensures a thorough and clean build, eliminating any uncertainty caused by residual old compilation results. It is suitable for initial project builds, official releases, or when dependencies undergo significant changes, guaranteeing the reliability of the results. For incremental compilation, the tool employs an intelligent analysis strategy for difference comparison. It also scans the entire patch project's source code directory to obtain a complete set of source files. Next, it checks if each source file has a corresponding, pre-compiled intermediate object file, compares the modification time of the source file with the generation time of the existing object file, and may also check if the header files the source file depends on have been updated. It identifies source files that have been updated, or whose critical dependencies have been updated, or whose object files are missing or corrupted. These are the source files that need to be recompiled, and their paths are collected to form a list of files to be compiled. Incremental compilation ensures that after each code modification, there is no need to wait for a lengthy full compilation process; the modified files can be compiled in a very short time for rapid verification.

[0041] Suppose a patch project has 100 source files, and the developer only modified one of them, security_fix.c. In incremental build mode, the list of files to be compiled generated after analysis by the tool will only contain security_fix.c, and the other 99 unchanged files will not appear in the task list for this compilation. In full build mode, all 100 files will appear in the task list for this compilation.

[0042] Determining the list of files to be compiled based on the compilation mode ensures that subsequent compilation resources are used precisely where they are most needed, laying the foundation for quickly generating effective hot patches.

[0043] Step 103: Read the kernel native symbols from the kernel executable file according to the length threshold of the kernel symbols, and construct a list of native symbols based on the kernel native symbols.

[0044] Kernel symbols, such as functions and variables within the kernel, all have names, which can be very long (e.g., highly descriptive function names). Traditional tools use a fixed-size buffer (e.g., 128 bytes). When a symbol name exceeds this size, it is truncated, causing incorrect matching and referencing in subsequent steps. The configured kernel symbol length threshold defines the maximum number of bytes allowed for a kernel symbol name. It determines how much memory buffer the tool should allocate internally to store the name of each symbol when resolving kernel symbols. For example, if the user sets the kernel symbol length threshold to 256, this means the tool will allocate a 256-byte buffer to read each symbol name, ensuring that even very long symbols are read completely.

[0045] A kernel executable file refers to a compiled, uncompressed, complete kernel image file, such as the vmlinux file. It contains all the kernel's code, data, and a complete symbol table (i.e., the definitions of all native kernel symbols). The kernel executable file is the source of native kernel symbols; it serves as a reference template for creating hot patches because the patch code needs to call or reference existing functions and variables in the kernel. Native kernel symbols are identifiers of all functions and variables defined by the kernel itself, resolved from the symbol table of the kernel executable file. They are inherent components of the kernel, constituting the programming interface and internal state provided by the kernel. Native kernel symbols can include function symbols, data symbols, etc. Function symbols include kmalloc (memory allocation function) and printk (kernel printing function); data symbols include jiffies (system clock counter) and init_task (initial process structure). These symbols act as a bridge between the patch code and the kernel, allowing the patch to call kernel functions or access kernel data. The native symbol list is a data structure built in memory by tools. It contains complete information about all native kernel symbols read and parsed from the kernel executable, including the full name, type (function or data), and memory address (or relative offset) of each symbol. The native symbol list is a crucial reference for subsequent compilation and linking stages. During compilation, the compiler uses it to verify the validity of symbols referenced in the patch code; during linking, the linker uses it to bind references to kernel symbols in the patch to the correct addresses.

[0046] The tool extracts all native kernel symbols completely and accurately from the kernel executable file based on a user-configured kernel symbol length threshold, organizing them into a structured list of native symbols. This provides data support for subsequent compilation and linking. The tool dynamically allocates a sufficiently large buffer based on the user-provided length threshold, ensuring that kernel symbols of any length can be read completely, fundamentally solving compatibility issues caused by symbol name truncation. The kernel executable file is an authoritative file containing all kernel details; the extracted list of native symbols is the basis for the patch code to safely and correctly call kernel functions, ensuring that the patch does not reference non-existent kernel functions or misinterpret kernel data structures. When the compiler processes the patch source code, upon encountering statements such as kmalloc (a memory allocation function), it recognizes that kmalloc is an external symbol that needs to be looked up in the list of native symbols, thus generating the correct reference instructions. The linker uses this list to fill all references to symbols such as kmalloc in the patch binary with the correct memory addresses.

[0047] For example, if the user specifies a kernel symbol length threshold of 256 bytes, a 256-byte buffer can be allocated, the vmlinux file opened, and its symbol table located. The first symbol is read, let's say its name is do_fast_encryption_for_network_packet_in_hardware_accelerated_mode (200 bytes long). Since the buffer is large enough, the name is read in its entirety. Its name, type (function), address (e.g., 0xffffffff81012345), and other information are recorded and stored in the native symbol list. This process is repeated until all symbols have been processed, forming a complete kernel function and data directory.

[0048] Step 104: Compile each source file in the list of files to be compiled according to the native symbol list to obtain the corresponding object files.

[0049] The native symbol list is a data structure or collection containing information on all native kernel symbols. Each entry records complete information about a kernel symbol resolved from the kernel executable. The native symbol list serves as a reference directory during the compilation process, ensuring that kernel functions and variables referenced by the patch code are legally valid and providing a binding basis for the subsequent linking stage. Source files are the patch source code files written in a programming language, containing the kernel functionality code that needs to be modified or added. The code in these files calls kernel functions and accesses kernel data structures, but does not contain the specific implementations of these kernel entities; it only contains reference declarations. Object files are the intermediate binary files generated after compiling the source files. They contain machine code, data, and unresolved symbol reference information. Object files cannot be executed directly because they contain references to external symbols (kernel functions, variables) that are not yet bound to specific addresses.

[0050] The tool processes each source file in the list of files to be compiled sequentially, invoking the compiler and converting it into the corresponding binary object file based on the kernel interface information provided by the native symbol list. The specific compilation process may include:

[0051] (1) Symbol verification and type checking. That is, when compiling each source file, the compiler will check all references to external kernel functions and variables in the code. These references need to match the symbol types (such as function prototypes and variable types) recorded in the native symbol list to ensure binary compatibility and prevent runtime crashes caused by interface mismatch.

[0052] (2) Generate unresolved symbol references. The compiler is not responsible for binding addresses to kernel symbols; it only generates a placeholder. For each kernel native symbol (such as printk) referenced in the code, the compiler leaves an empty space at a specific location in the object file and records a note: the address of printk will be filled in here later.

[0053] (3) Generate the final target file. For each source file, generate a corresponding binary intermediate file, which contains the machine code for patching, the data for patch definition, and the symbols provided by this file.

[0054] Step 105: Link the target files to obtain the linked file, and add the target kernel version identifier to the linked file to obtain the target kernel patch.

[0055] Linking is a core process that merges and assembles multiple independent object files into a single, complete executable module. It primarily addresses the issue of unbound symbol references left over from the compilation phase. The core tasks of linking include symbol resolution, which binds placeholder references to external symbols (mainly kernel functions / variables) in each object file to their actual addresses in the kernel's native symbol list; address relocation, which modifies machine instructions and data references in the object files based on the bound addresses; and section merging, which merges similar data (such as code sections and data sections) from different object files. The linker file is the preliminary result generated after the linking process; it is a prototype kernel module file that does not yet contain the correct version identifier. In the process of this invention, it is the direct object for adding the final version identifier. The linker file is already a complete binary module; all symbol references have been resolved, code addresses have been determined, and it has the ability to run. However, at this point, the version information recorded internally is usually still the version of the compilation environment, and therefore it cannot be loaded by target kernels of different versions. The target kernel patch is the final output of the entire method. It is a complete, loadable kernel module file that carries the correct target version identifier. This file has been fully processed and can be loaded by the loader into the specified target kernel for execution.

[0056] The scattered object files are integrated into a unified linker file through an enhanced linking process. For most kernel symbols, their addresses can be found in the native symbol list and filled in. If a symbol does not exist in the native symbol list (e.g., due to kernel configuration differences), the linker will query the custom symbol definition parameters. If a match is found, this custom symbol is injected, allowing linking to continue instead of terminating with an error. Before generating the final binary file, all symbols can be automatically scanned, and malformed or invalid symbols can be removed. Finally, an identity rewriting operation is performed on this file, marking its internal version information with the version identifier of the target kernel specified by the user, thus generating the final usable patch.

[0057] In this embodiment, the "target kernel version identifier" configuration information is introduced. When generating patches, the target kernel version is actively marked, ensuring that the patches can be accepted by the target kernel loader and decoupling the compilation environment from the runtime environment. Even if the kernel executable version used during compilation differs from the kernel version currently running in the system, as long as the core interfaces are compatible, the generated hot patch can be verified by the version identifier and successfully loaded, breaking the rigid constraints of existing technologies. Operations personnel no longer need to maintain a complete compilation environment and high-precision kernel executable for each minor kernel version; they can more flexibly choose available compilation bases, significantly reducing the complexity and cost of environment maintenance, making it possible to batch create and distribute patches for a large number of different minor kernel versions. Through the "kernel symbol length threshold" configuration, the symbol resolution length is dynamically adjusted, enabling the complete reading and parsing of extremely long function names and complex symbols that may appear in modern kernels, avoiding reference or loading errors caused by symbol truncation. The "compile mode" configuration allows users to choose according to different scenarios and flexibly adopt different compilation modes. For example, when "incremental compilation" is configured, it can automatically identify and recompile only the source files that have changed, reuse the existing compilation results, and after fixing a minor error, there is no need to go through a long full compilation wait, which greatly shortens the compilation time and improves development and debugging efficiency.

[0058] The kernel patch creation method provided in the embodiments of the present invention is further described below, such as... Figure 2 As shown, Figure 2 This is another schematic flowchart of the kernel patch creation method provided in this embodiment of the invention. The kernel patch creation method in this embodiment may include:

[0059] Step 201: Receive the compilation mode, kernel symbol length threshold, target kernel version identifier, and kernel custom symbol definition information input by the user through a preset command line.

[0060] Predefined command lines are a set of parameterized instruction interfaces predefined for kernel hot patching tools. These refer to a set of command options that the tool can recognize and process, each beginning with a predefined prefix (such as `--`). Custom symbol definition information is a symbol definition parameter that allows the user to provide a manual, supplementary definition for symbols that are missing or undefined in the compilation environment. For example: `--def_sym deprecated_helper, 0`. This means that if a symbol named `deprecated_helper` is not defined, its address is treated as 0 (NULL). This is an emergency or auxiliary function that allows the compilation and linking process to continue in the event of a missing symbol, rather than stopping with an error. This is crucial for handling non-critical symbol missingness due to kernel configuration differences, or for quickly bypassing minor issues during development.

[0061] Step 202: Store the compilation mode, the length threshold of kernel symbols, the version identifier of the target kernel, and the definition information of kernel custom symbols into the preset configuration structure.

[0062] A pre-defined configuration structure is a data structure pre-defined within the tool. Its purpose is to serve as a unified, structured container to centrally store and manage all configuration information parsed from user input. This structure provides a basis for decision-making in subsequent intelligent processing, for example:

[0063] When the process reaches the point of determining the list of files to be compiled, it will query config.build_mode.

[0064] When reading kernel native symbols, the system will query config.symbol_length_limit.

[0065] When encountering an undefined symbol during linking, config.custom_syms will be queried.

[0066] When adding the version identifier at the end, it will query config.target_version.

[0067] By adopting a preset configuration structure, the user's command-line input is transformed into a structured configuration object that can be efficiently, stably, and continuously accessed within the tool, providing a decision-making basis for subsequent intelligent processing.

[0068] Step 203: Obtain patch creation configuration information from the preset configuration structure. The patch creation configuration information includes compilation mode, kernel symbol length threshold, target kernel version identifier, and kernel custom symbol definition information.

[0069] Step 204: Determine the list of files to be compiled based on the compilation mode.

[0070] The compilation mode includes full compilation or incremental compilation. In the case of full compilation, a list of files to be compiled, including all source files, is constructed. In the case of incremental compilation, the source files to be compiled are determined from all source files based on all source files and existing object files, and a list of files to be compiled, including the source files to be compiled, is constructed.

[0071] Step 205: Read the kernel native symbols from the kernel executable file according to the length threshold of the kernel symbols, and construct a list of native symbols based on the kernel native symbols.

[0072] Step 206: Compile each source file in the list of files to be compiled according to the native symbol list to obtain the corresponding object files.

[0073] Step 207: Link the target files to obtain the linked file.

[0074] Step 208: Identify symbols from the symbols referenced in the linked file that do not match the kernel native symbols in the native symbol list, and obtain undefined symbols.

[0075] Undefined symbols, or mismatched symbols, refer to symbols referenced in the linker file but for which no corresponding entry can be found in the native symbol list. These symbols failed the standard symbol resolution process. Undefined symbols may arise because: the symbol does not exist in the kernel (e.g., a spelling error); the symbol exists in the target kernel but was not compiled into the currently used kernel executable due to kernel configuration differences; or the symbol is from a kernel module and not in the core kernel image. Failure to handle undefined symbols will cause linking failures, preventing the linker from allocating the correct memory address and leaving gaps in the final executable file.

[0076] During the linking phase, the linker systematically checks all symbol references in the linked file that require external definition, comparing them with a pre-generated list of native symbols. For each symbol, if no matching entry with the same name and type is found in the list, the symbol is marked as undefined. For example, if a patch needs to call a helper function `legacy_helper` from an older kernel version, but the kernel executable used is from a newer version where `legacy_helper` has been removed or renamed, the linker finds that the patch references `legacy_helper`, queries the list of native symbols (from the newer kernel version), and finds that the symbol is not in the list, `legacy_helper` is identified as a mismatched symbol and thus confirmed as undefined.

[0077] Step 209: Identify the kernel custom symbols corresponding to undefined symbols from the kernel custom symbols.

[0078] Kernel custom symbols are typically a list, with each entry containing a symbol name and a value assigned to it (such as an address). For example: {"symbol_A", 0x0}, {"deprecated_helper", 0}. Kernel custom symbols act as an external knowledge base or supplementary library, allowing tools to query this library and obtain a workable definition when encountering undefined symbols that standard procedures cannot resolve, thus enabling the process to continue rather than fail and be interrupted. The name of the undefined symbol can be used as the lookup key to search the list of custom symbols; an entry with the same name is considered the corresponding custom symbol.

[0079] After obtaining the list of undefined symbols generated in the previous step, the tool uses each symbol name in this list as a query criterion to retrieve the user-provided list of custom symbol definitions. For each undefined symbol, if an entry with the exact same name can be found in the custom list, that entry is identified as a valid solution corresponding to that undefined symbol.

[0080] Step 210: Add the definition information of the identified kernel custom symbols to the linker file.

[0081] Definition information refers to the specific technical definition content of a custom symbol entry, excluding the symbol name. Its main content is the address value assigned to the symbol (such as 0 or 0xdeadbeef). It may also include metadata such as the symbol's type (e.g., function, data).

[0082] The specific definition information (such as addresses) of the successfully matched kernel custom symbols is formally integrated into the internal structure of the linker file as a new symbol definition, thereby providing a legal and linkable target for the previously dangling symbol references, enabling the linking process to complete.

[0083] For example, if the undefined symbol is `deprecated_helper`, and the corresponding recognized custom symbol entry is `{"deprecated_helper", 0}`, and there's an instruction at offset 0x2010 that requires the address of this function, then we can add the following to the symbol table of the linker file: `[Name: deprecated_helper, Value: 0x0]`. The linker finds the record in the relocation table that indicates "address of deprecated_helper needs to be filled at location 0x2010", calculates address 0x0, and fills it into the instruction at location 0x2010. The linking process, which was about to fail due to the undefined `deprecated_helper`, now successfully generates a valid linker file. In this file, the call to `deprecated_helper` is directed to address 0.

[0084] By injecting symbol definitions into the intermediate binary file, the hard linking failure caused by missing symbols is bypassed.

[0085] Step 211: Identify invalid format symbols from the symbols referenced in the linked file.

[0086] Invalid symbol formats refer to symbols whose string names do not conform to the kernel loader's expected format and therefore cannot be resolved correctly. These symbols are usually unexpected byproducts of complex processing by the linker or other tools, rather than intentionally defined by the developers. When the kernel loader verifies patches, if it attempts to resolve such incorrectly formatted symbols, it will reject the entire module due to its inability to understand its structure, leading to loading failure.

[0087] Step 212: Remove invalid format symbols from the symbols referenced in the linked file.

[0088] Cleaning up invalid symbols can include deleting the symbol entry from the symbol table data structure, updating metadata such as the size and index of the symbol table, and ensuring consistency for any other parts that depend on the symbol table structure (such as hash tables and string tables).

[0089] Step 213: Add the target kernel version identifier to the linker file to obtain the target kernel patch.

[0090] The version identifier of the target kernel specified by the user is written as identity information into the metadata of the linker file. Through this operation, the intermediate file, which originally carried the version information of the compilation environment, is transformed into a final, usable patch file that explicitly claims compatibility with the target running kernel.

[0091] Assuming the compilation environment uses kernel version 3.10.0-1127 (the reference kernel used to create the patch), and the user specifies the target version as 3.10.0-1160 (the kernel used on the running production server), the linker file `patch_linked.ko` has a `vermagic` field value of 3.10.0-1127. The tool reads the target identifier 3.10.0-1160 from the configuration, opens `patch_linked.ko`, locates the `vermagic` field, and replaces its value with 3.10.0-1160. The file is saved, generating the final patch `patch_final.ko`. When `patch_final.ko` is loaded on the production server, the kernel loader checks its `vermagic` field and finds it to be 3.10.0-1160, which is completely consistent with the currently running kernel version, thus passing the compatibility check.

[0092] In practice, the version identifier of the kernel executable file is the same as the version identifier of the target kernel. Alternatively, the version identifier of the kernel executable file is different from the version identifier of the target kernel, but the interface that the patch depends on is compatible with the corresponding interface in the target kernel.

[0093] Compatibility is best guaranteed when the kernel versions of the compilation and runtime environments are completely identical; this is a prerequisite for traditional hot patching tools. Due to asynchronous operation and maintenance cycles, the version of the compilation environment (vmlinux) and the production environment (target kernel) may differ. This invention allows for different version numbers, but establishes a new, more intelligent admission standard—interface compatibility. The interfaces that the patch depends on refer to the kernel functions and data structures actually called or accessed in the hot patch code, not all interfaces of the entire kernel, but only the parts used by the patch. The corresponding interfaces in the target kernel are the functions and data structures in the target kernel with the same name and function as those called by the patch. Compatibility can specifically include:

[0094] Functions with identical signatures: function name, parameter type / number / order, and return type are completely identical.

[0095] The data structure layout is the same: the type, order, and memory offset of the member variables within the structure are unchanged.

[0096] Symbolic semantic consistency: The function's functionality and behavior have not changed significantly.

[0097] Suppose the production server is running kernel 3.10.0-1160, but the system administrator only has vmlinux version 3.10.0-1127 for compilation. Traditionally, the compiled patch would be rejected due to the version number difference (1160 and 1127). According to the method of this invention, analysis revealed that all kernel functions called by the patch (such as kmalloc, printk, etc.) have unchanged function prototypes and data structures in both versions 1160 and 1127 (i.e., interface compatibility). Therefore, when generating the patch, the target version can be forcibly marked as 3.10.0-1160 using the `--version` parameter. The resulting patch file, because its declared version matches the running kernel and the actual called interfaces are compatible, can be successfully loaded.

[0098] In this embodiment, the "target kernel version identifier" configuration information is introduced. When generating patches, the target kernel version is actively marked, ensuring that the patches can be accepted by the target kernel loader and decoupling the compilation environment from the runtime environment. Even if the kernel executable version used during compilation differs from the kernel version currently running in the system, as long as the core interfaces are compatible, the generated hot patch can be verified by the version identifier and successfully loaded, breaking the rigid constraints of existing technologies. Operations personnel no longer need to maintain a complete compilation environment and high-precision kernel executable for each minor kernel version; they can more flexibly choose available compilation bases, significantly reducing the complexity and cost of environment maintenance, making it possible to batch create and distribute patches for a large number of different minor kernel versions. Through the "kernel symbol length threshold" configuration, the symbol resolution length is dynamically adjusted, enabling the complete reading and parsing of extremely long function names and complex symbols that may appear in modern kernels, avoiding reference or loading errors caused by symbol truncation. The "compile mode" configuration allows users to choose according to different scenarios and flexibly adopt different compilation modes. For example, when "incremental compilation" is configured, it can automatically identify and recompile only the source files that have changed, reuse the existing compilation results, and after fixing a minor error, there is no need to go through a long full compilation wait, which greatly shortens the compilation time and improves development and debugging efficiency.

[0099] Figure 3 This is an example diagram of the kernel patch creation method provided in this embodiment of the invention, such as... Figure 3 As shown, it can be divided into three stages:

[0100] (1) Configuration check and parsing stage.

[0101] After the tool starts, it first checks whether the user has provided four key parameters:

[0102] Version parameter: Determines the target kernel version identifier for the patch.

[0103] Symbol length parameter: Determines the length threshold used when resolving kernel symbols.

[0104] Compilation mode parameter: Determines whether to use full compilation or incremental compilation.

[0105] Custom parameters: Retrieves custom symbol definition information used to handle undefined symbols.

[0106] If the user configures a parameter, the tool will parse and use it; otherwise, it will use the default logic. For example, if the version parameter is not configured, the default kernel version of the compilation environment will be used; if the symbol length parameter is not configured, the default length will be used; if the compilation mode parameter is not configured, a full compilation will be performed, and so on.

[0107] (2) Compilation and processing stage.

[0108] Determine the compilation mode: Based on the configuration, decide whether to compile fully or incrementally.

[0109] Determine symbol length: Set the buffer size according to the configuration to ensure that long symbol names can be read.

[0110] Add definition information: If the user provides custom symbols, add them to the processing environment to resolve potential linking errors.

[0111] At this stage, the tool calls the compiler to compile the source code into binary object files and performs preliminary linking and symbol processing.

[0112] (3) Generation and labeling stage.

[0113] Add version identifier: Writes the version identifier of the target kernel specified by the user into the metadata of the file to be generated.

[0114] Generate hot patch file: After all processing is complete, the final usable hot patch file is output.

[0115] The behavior of the tool (how to compile, who to patch) is controlled by user-input parameters. Each key step takes into account both configured and unconfigured cases, ensuring that the process has a clear execution path under any input.

[0116] Figure 4 This is a schematic diagram of a kernel patch creation apparatus provided in an embodiment of the present invention, as shown below. Figure 4 As shown, the device includes:

[0117] The acquisition module 401 is used to acquire patch creation configuration information, which includes compilation mode, kernel symbol length threshold and target kernel version identifier.

[0118] The determination module 402 is used to determine the list of files to be compiled based on the compilation mode;

[0119] The reading module 403 is used to read kernel native symbols from the kernel executable file according to the length threshold of the kernel symbols, and to construct a list of native symbols based on the kernel native symbols;

[0120] The compilation module 404 is used to compile each source file in the list of files to be compiled according to the native symbol list, so as to obtain each target file.

[0121] Linking module 405 is used to link the various target files to obtain a linked file, and to add the version identifier of the target kernel to the linked file to obtain a patch for the target kernel.

[0122] In one embodiment, the compilation mode includes full compilation or incremental compilation, and the determining module 402 determines a list of files to be compiled according to the compilation mode, including:

[0123] When the compilation mode is full compilation, a list of files to be compiled, including all source files, is constructed.

[0124] When the compilation mode is incremental compilation, the source files to be compiled are determined from all source files based on all source files and existing object files, and a list of files to be compiled, including the source files to be compiled, is constructed.

[0125] In one embodiment, when the compilation mode is incremental compilation, the linking module 405 links the various object files, including:

[0126] Link the source files in the list of files to be compiled to the corresponding object files and the existing object files.

[0127] In one embodiment, the patch creation configuration information further includes the definition information of kernel custom symbols, and before the linker module 405 adds the version identifier of the target kernel to the linker file, it also includes:

[0128] Undefined symbols are obtained by identifying symbols from the symbols referenced in the linked file that do not match the kernel native symbols in the list of native symbols;

[0129] Identify the kernel-defined symbol corresponding to the undefined symbol from the kernel-defined symbols;

[0130] Add the definition information of the identified kernel custom symbols to the linker file.

[0131] In one embodiment, before the linker module 405 adds the target kernel version identifier to the linker file, the method further includes:

[0132] Identify invalid format symbols from the symbols referenced in the linked file;

[0133] Remove the invalid format symbols from the symbols referenced in the linked file.

[0134] In one embodiment, the acquisition module 401 acquires patch creation configuration information, including:

[0135] The compiler receives the compilation mode, the length threshold of the kernel symbol, and the version identifier of the target kernel from the user via a preset command line.

[0136] The compilation mode, the length threshold of the kernel symbol, and the version identifier of the target kernel are stored in a preset configuration structure;

[0137] Obtain the patch creation configuration information from the preset configuration structure.

[0138] In one embodiment, the version identifier of the kernel executable file is the same as the version identifier of the target kernel; or

[0139] The version identifier of the kernel executable file is different from the version identifier of the target kernel, but the interface that the patch depends on is compatible with the corresponding interface in the target kernel.

[0140] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional modules is merely an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the functional modules described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0141] The apparatus of this invention introduces the configuration information of "target kernel version identifier" to actively mark the target kernel version when generating patches, ensuring that the patches can be accepted by the target kernel loader and decoupling the compilation environment from the runtime environment. Even if the kernel executable file version used during compilation is different from the kernel version currently running in the system, as long as the core interfaces are compatible, the generated hot patch can be verified by the version identifier and successfully loaded, breaking the rigid constraints of existing technologies. Operation and maintenance personnel do not need to maintain a complete compilation environment and high-precision kernel executable file for each minor kernel version, and can more flexibly choose available compilation bases, significantly reducing the complexity and cost of environment maintenance, making it possible to batch create and distribute patches for a large number of different minor kernel versions. By configuring the "kernel symbol length threshold," the symbol resolution length is dynamically adjusted, enabling the complete reading and parsing of extremely long function names and complex symbols that may appear in modern kernels, avoiding reference or loading errors caused by symbol truncation. The "compile mode" configuration allows users to choose according to different scenarios and flexibly adopt different compilation modes. For example, when "incremental compilation" is configured, it can automatically identify and recompile only the source files that have changed, reuse the existing compilation results, and after fixing a minor error, there is no need to go through a long full compilation wait, which greatly shortens the compilation time and improves development and debugging efficiency.

[0142] The following is for reference. Figure 5 It shows a schematic diagram of the structure of a computer system 500 suitable for implementing an electronic device according to embodiments of the present invention. Figure 5 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0143] like Figure 5 As shown, the computer system 500 includes a central processing unit (CPU) 501, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 502 or programs loaded from storage section 508 into random access memory (RAM) 503. The RAM 503 also stores various programs and data required for the operation of the computer system 500. The CPU 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0144] The following components are connected to I / O interface 505: input section 506 including keyboard, mouse, etc.; output section 507 including cathode ray tube, liquid crystal display, etc., and speakers, etc.; storage section 508 including hard disk, etc.; and communication section 509 including network interface card, such as modem, etc. Communication section 509 performs communication processing via a network such as the Internet. Drive 510 is also connected to I / O interface 505 as needed. Removable media 511, such as disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 510 as needed so that computer programs read from them can be installed into storage section 508 as needed.

[0145] In particular, according to the embodiments disclosed in this invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 509, and / or installed from removable medium 511. When the computer program is executed by central processing unit (CPU) 501, it performs the functions defined above in the system of this invention.

[0146] It should be noted that the computer-readable medium shown in this invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, a random access memory, a read-only memory, an erasable programmable read-only memory, an optical fiber, a portable compact disk read-only memory, an optical storage device, a magnetic storage device, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this invention, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, etc., or any suitable combination thereof.

[0147] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0148] The modules and / or units described in the embodiments of this invention can be implemented in software or hardware. The described modules and / or units can also be housed in a processor; for example, a processor can be described as including an acquisition module, a determination module, a reading module, a compilation module, and a linking module. The names of these modules do not necessarily limit the module itself.

[0149] In another aspect, the present invention also provides a computer-readable medium, which may be included in the device described in the above embodiments; or it may exist independently and not assembled into the device. The computer-readable medium carries one or more programs, which, when executed by the device, cause the device to include:

[0150] Obtain patch creation configuration information, including compilation mode, kernel symbol length threshold, and target kernel version identifier; determine a list of files to be compiled based on the compilation mode; read native kernel symbols from the kernel executable file based on the kernel symbol length threshold, and construct a native symbol list based on the native kernel symbols; compile each source file in the list of files to be compiled according to the native symbol list to obtain corresponding target files; link the target files to obtain a linked file, and add the target kernel version identifier to the linked file to obtain the patch for the target kernel.

[0151] The technical solution of this invention introduces the configuration information of "target kernel version identifier," which actively marks the target kernel version when generating patches, ensuring that the patches can be accepted by the target kernel loader and decoupling the compilation environment from the runtime environment. Even if the kernel executable file version used during compilation is different from the kernel version currently running in the system, as long as the core interfaces are compatible, the generated hot patch can be verified by the version identifier and successfully loaded, breaking the rigid constraints of existing technologies. Operation and maintenance personnel do not need to maintain a complete compilation environment and high-precision kernel executable file for each minor kernel version, allowing for more flexible selection of available compilation bases, significantly reducing the complexity and cost of environment maintenance, and making it possible to batch create and distribute patches for a large number of different minor kernel versions. By configuring the "kernel symbol length threshold," the symbol resolution length is dynamically adjusted, enabling the complete reading and parsing of extremely long function names and complex symbols that may appear in modern kernels, avoiding reference or loading errors caused by symbol truncation. The "compile mode" configuration allows users to choose according to different scenarios and flexibly adopt different compilation modes. For example, when "incremental compilation" is configured, it can automatically identify and recompile only the source files that have changed, reuse the existing compilation results, and after fixing a minor error, there is no need to go through a long full compilation wait, which greatly shortens the compilation time and improves development and debugging efficiency.

[0152] This invention also provides a computer program product, including a computer program that, when executed by a processor, implements the kernel patch creation method provided in any embodiment of this invention.

[0153] In the implementation of a computer program product, computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages ​​as well as conventional procedural programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including local area networks (LANs) or wide area networks (WANs), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0154] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0155] It should be noted that the collection, use, storage, sharing, and transfer of user personal information involved in the technical solution of this invention all comply with the provisions of relevant laws and regulations, and require notification to the user and obtaining the user's consent or authorization. Where applicable, user personal information has undergone de-identification and / or anonymization and / or encryption technical processing. In addition, a corresponding operation entry is provided for the user to choose to agree to or reject the automated decision result; if the user chooses to reject, the process proceeds to the expert decision-making process.

[0156] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for creating kernel patches, characterized in that, include: Obtain patch creation configuration information, which includes compilation mode, kernel symbol length threshold, and target kernel version identifier; Determine the list of files to be compiled based on the compilation mode; Kernel native symbols are read from the kernel executable file according to the length threshold of the kernel symbols, and a list of native symbols is constructed based on the kernel native symbols; The source files in the list of files to be compiled are compiled according to the native symbol list to obtain the corresponding target files; The target files are linked together to obtain a linked file, and the version identifier of the target kernel is added to the linked file to obtain a patch for the target kernel.

2. The method according to claim 1, characterized in that, The compilation mode includes full compilation or incremental compilation. Based on the compilation mode, a list of files to be compiled is determined, including: When the compilation mode is full compilation, a list of files to be compiled, including all source files, is constructed. When the compilation mode is incremental compilation, the source files to be compiled are determined from all source files based on all source files and existing object files, and a list of files to be compiled, including the source files to be compiled, is constructed.

3. The method according to claim 2, characterized in that, When the compilation mode is incremental compilation, linking the various object files includes: Link the source files in the list of files to be compiled to the corresponding object files and the existing object files.

4. The method according to claim 1, characterized in that, The patch creation configuration information also includes the definition information of kernel custom symbols, and before adding the version identifier of the target kernel to the linker file, it also includes: Undefined symbols are obtained by identifying symbols from the symbols referenced in the linked file that do not match the kernel native symbols in the list of native symbols; Identify the kernel-defined symbol corresponding to the undefined symbol from the kernel-defined symbols; Add the definition information of the identified kernel custom symbols to the linker file.

5. The method according to claim 1, characterized in that, Before adding the target kernel version identifier to the linked file, the following is also included: Identify invalid format symbols from the symbols referenced in the linked file; Remove the invalid format symbols from the symbols referenced in the linked file.

6. The method according to claim 1, characterized in that, Obtain patch creation configuration information, including: The compiler receives the compilation mode, the length threshold of the kernel symbol, and the version identifier of the target kernel from the user via a preset command line. The compilation mode, the length threshold of the kernel symbol, and the version identifier of the target kernel are stored in a preset configuration structure; Obtain the patch creation configuration information from the preset configuration structure.

7. The method according to claim 1, characterized in that: The version identifier of the kernel executable file is the same as the version identifier of the target kernel; or The version identifier of the kernel executable file is different from the version identifier of the target kernel, but the interface that the patch depends on is compatible with the corresponding interface in the target kernel.

8. A kernel patch creation device, characterized in that, include: The acquisition module is used to acquire patch creation configuration information, which includes compilation mode, kernel symbol length threshold and target kernel version identifier; The determination module is used to determine the list of files to be compiled based on the compilation mode. The reading module is used to read kernel native symbols from the kernel executable file according to the length threshold of the kernel symbols, and to construct a list of native symbols based on the kernel native symbols; The compilation module is used to compile each source file in the list of files to be compiled according to the native symbol list, so as to obtain each target file. The linking module is used to link the various target files to obtain a linked file, and to add the version identifier of the target kernel to the linked file to obtain a patch for the target kernel.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, The processor executes a program to implement the kernel patch creation method as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by the processor, the program implements the kernel patching method as described in any one of claims 1 to 7.

Images