A method and system for binary compatibility between Linux-based kernel images and modules

Abstract

The application discloses a kind of binary compatibility method and system between Linux-based kernel image and module, method includes the following steps: obtaining the list of white list function, the eigenvalue of each white list function in the list is calculated and saved;When kernel image compilation or driver module compilation is carried out, function is sequentially taken out from array, the eigenvalue of function taken out is matched with the eigenvalue that has been saved, if there is matching result and eigenvalue is consistent, export function taken out and carry out compilation in unified binary compilation environment, the compilation environment of kernel image and driver module is uniformly encapsulated into container in unified binary compilation environment, simultaneously, using custom compilation tool chain and using same compilation parameter to compilation process, so as to guarantee the compatibility from source code level to binary level.The application realizes the environment of operating system kernel image and kernel module separation compilation, guarantees that kernel module can be smoothly loaded after separation compilation and function is normal.

Description

Technical Field

[0001] This invention relates to the field of Linux kernel compilation, and more specifically to a method and system for binary compatibility between Linux kernel images and modules. Background Technology

[0002] With the widespread adoption of the Linux operating system in servers, embedded devices, and cloud computing platforms, long-term system stability and maintainability have become critical requirements. The Linux kernel employs a monolithic kernel architecture, where many hardware drivers and system functions exist as kernel modules that can be dynamically loaded into kernel space. However, this architecture creates tight symbolic dependencies and interface coupling between the kernel and modules. Existing mechanisms strictly require that the kernel and kernel modules be compiled based on completely identical kernel versions and build configurations to ensure correct loading and execution. Any version or configuration mismatch can directly lead to module loading failures or even system crashes.

[0003] In actual operation and maintenance deployments, kernel upgrades and driver upgrades are often handled by different teams or vendors, making it difficult to keep their upgrade schedules in sync. For example, fixing security vulnerabilities requires timely kernel version updates, but corresponding hardware drivers may not be compatible due to vendor update delays; conversely, bug fixes or feature enhancements for drivers themselves are often constrained by the user-side kernel version, preventing timely deployment. This high coupling between the kernel and modules severely restricts the flexibility and reliability of system updates, leading to high maintenance costs and reduced collaborative efficiency across the entire ecosystem. Therefore, an effective technical solution is urgently needed to overcome this long-standing compatibility bottleneck.

[0004] In the existing technology, although the industry has adopted mechanisms such as ABI (Application Binary Interface) tracing to try to alleviate the compatibility problem between the kernel and modules, these methods still have fundamental limitations and cannot completely solve the binary compatibility break caused by kernel version iteration.

[0005] The shortcomings of the existing solution can be summarized as follows: 1) Poor system upgrade flexibility: Upgrading the kernel or any functional module individually requires recompiling all dependent components, which not only significantly increases the complexity and time cost of deployment, but may also introduce new compilation errors or unforeseen compatibility issues in the process.

[0006] 2) High maintenance costs: To maintain strict version consistency, system operators must precisely coordinate the version matching of the kernel and all modules. In large distributed environments with a large number of nodes, this coordination and management work becomes extremely difficult and prone to errors.

[0007] 3) Low efficiency of ecosystem collaboration: For hardware manufacturers, multiple driver binary packages must be continuously provided for different kernel versions, which greatly increases their development, building and testing burden; while for end users, they often face the dilemma that the required drivers cannot be adapted to the new kernel version in time, thus delaying or hindering system updates.

[0008] In summary, existing technologies have failed to achieve binary program compatibility between the kernel and kernel modules under the premise of separate binary compilation. This has become a key technical obstacle restricting the modernization deployment and maintenance of Linux systems. Summary of the Invention

[0009] The technical problem to be solved by this invention is to provide a binary compatibility method and system based on Linux kernel images and modules, which aims to solve the binary program compatibility problem between the operating system kernel and kernel modules under the premise of binary separate compilation, realize the environment of separate compilation of operating system kernel images and kernel modules, and ensure that the kernel modules can be loaded smoothly and function normally after separate compilation.

[0010] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: A method for achieving binary compatibility between Linux kernel images and modules includes the following steps: Obtain a list of whitelisted functions, calculate and save the feature value of each whitelisted function in the list, wherein the whitelisted functions are functions applied for by the device driver vendor and reviewed by the kernel image vendor; When compiling a kernel image or kernel module, functions are sequentially retrieved from the array, and the feature values ​​of the retrieved functions are matched with the saved feature values. If a match is found and the feature values ​​are consistent, the retrieved function is exported and compiled in a unified binary compilation environment. The unified binary compilation environment encapsulates the compilation environments of kernel images and driver modules into a container, and uses a customized compilation toolchain and the same compilation parameters for the compilation process, thereby ensuring compatibility from the source code level to the binary level.

[0011] Furthermore, when calculating and saving the feature values ​​of each whitelisted function in the list, specifically for the same function, the function name, the type of the function's input parameters, the function's return value, the function's source code path, the compilation architecture identifier, the compilation macro configuration, and the dependent file signature are converted into strings. Then, the CRC check value of the string is calculated as the feature value corresponding to the function, and the feature value of the function is saved along with the function name.

[0012] Furthermore, before retrieving functions sequentially from the array, the process also includes: If a kernel image is compiled, the functions in the whitelist file are parsed and stored in an array; If the driver module is compiled, the external functions used in the module code are analyzed and stored in an array.

[0013] Furthermore, if a kernel image compilation is performed, when the feature values ​​of the extracted functions are matched against the saved feature values, this includes: The name of the function to be extracted, the types of the parameters passed to the function, the return value of the function, the source code path of the function, the compilation architecture identifier, the compilation macro configuration, and the dependent file signature are converted into a string. Then, the CRC check value of the string is calculated and used as the feature value T1 of the extracted function. Get the feature value T2 corresponding to the saved function with the same name, and compare the feature value T1 with the feature value T2; If feature value T1 is not equal to feature value T2, an interface exception is indicated and compilation stops; if feature value T1 is equal to feature value T2, the extracted function is exported to the external interface of the kernel image, and then the next function is extracted from the array. The feature value of the extracted function is matched with the saved feature value again, until all functions in the array are extracted.

[0014] Furthermore, if kernel module compilation is performed, when the feature values ​​of the extracted function are matched with the saved feature values, this includes: Determine if the extracted function is a whitelisted function. If it is not a whitelisted function, output an error message and terminate. If it is a whitelist function, the name of the function to be extracted, the type of the parameters passed to the function, the return value of the function, the source code path of the function, the compilation architecture identifier, the compilation macro configuration, and the signature of the dependent files are converted into a string, and then the CRC check value of the string is calculated as the feature value T1 of the extracted function; Get the feature value T2 corresponding to the saved function with the same name, and compare the feature value T1 with the feature value T2; If feature value T1 is not equal to feature value T2, an interface exception is indicated and compilation stops; if feature value T1 is equal to feature value T2, the next function is retrieved from the array, and the feature value of the retrieved function is matched with the saved feature value again, until all functions in the array are retrieved.

[0015] The present invention also proposes a binary compatibility system between Linux kernel images and modules, comprising interconnected processors and computer-readable storage media, wherein the computer-readable storage media stores a computer program, which is executed by the processor to implement the steps of the binary compatibility method between Linux kernel images and modules.

[0016] Compared with the prior art, the advantages of the present invention are as follows: The unified binary compilation environment of this invention ensures that the generated binary code is also compatible by unifying the compilation and build environment and compilation and build parameters of the kernel and driver modules; This invention extracts the feature values ​​of whitelist functions and uses these feature values ​​as unique characteristics of the source code interface. Different interfaces have different feature values, thus ensuring the compatibility of the source code interface. This invention performs kernel image compilation verification. During the compilation of the kernel image, the feature values ​​of all functions in the whitelist are compared with the feature values ​​in the database to ensure that the upgrade and modification of the source code will not break the compatibility of the source code interface, thereby ensuring binary compatibility. This invention performs kernel module compilation verification. During module compilation, the whitelist and feature values ​​of externally used interface functions are compared to ensure that all external functions are in the whitelist and that the feature values ​​have not changed. This ensures that modifications and upgrades to the driver code will not break the compatibility of the source code interface, thereby guaranteeing binary compatibility. Attached Figure Description

[0017] Figure 1 The following are brief steps of the method according to an embodiment of the present invention.

[0018] Figure 2 This is the whitelist feature value extraction process in an embodiment of the present invention.

[0019] Figure 3 This is the process for determining the stability of the whitelist interface of the kernel image in this embodiment of the invention.

[0020] Figure 4 This is the process for determining the stability of the external interface of the module in this embodiment of the invention. Detailed Implementation

[0021] The present invention will be further described below with reference to the accompanying drawings and specific preferred embodiments, but this does not limit the scope of protection of the present invention.

[0022] Before introducing specific embodiments of the present invention, the relevant concepts or terms will be explained.

[0023] Driver module: A driver module is a software component in the operating system kernel used to manage and control specific hardware devices, and is responsible for establishing a communication bridge between the operating system and the hardware.

[0024] Compilation: Compilation refers to the process of converting source code written in a high-level programming language into machine-executable binary code.

[0025] Toolchain: A toolchain is a complete set of tools used for software development, which typically includes compilers, linkers, debuggers, library files, etc., and is used to build source code into executable programs or kernel modules.

[0026] Whitelist: Here, whitelist refers to a set of function names used by the driver to call functions in the kernel. These are functions exported by the kernel for the driver to use.

[0027] Example This embodiment proposes a binary compatibility method based on Linux kernel images and modules. The overall idea is to achieve binary interface compatibility through source code-level compatibility and a unified binary compilation environment. Figure 1 As shown, the method includes the following steps: S101) Establish a unified binary compilation environment.

[0028] To ensure compatibility from the source code level to the binary level, this embodiment encapsulates the compilation environment of the kernel image and driver module into a unified container, ensuring that the environment is exactly the same for each compilation and build. At the same time, a customized compilation toolchain and the same compilation parameters are used for the compilation process, thereby ensuring compatibility from the source code level to the binary level.

[0029] S102) Define a whitelist of functions.

[0030] The interface between the kernel image and driver modules is strictly managed through a whitelist of functions. All external functions used by driver modules must be functions on the whitelist; if a function is not on the whitelist, the module is not allowed to compile. The whitelist is submitted by each device driver vendor and reviewed and added to the whitelist by the kernel image vendor.

[0031] S103) Extract the feature values ​​of the whitelist function.

[0032] Obtain a list of whitelisted functions, calculate the feature value of each whitelisted function in the list, and save it.

[0033] In this embodiment, the whitelist serves as the interface between the kernel image and the driver module, forming the foundation for binary compatibility. Binary compatibility is achieved by extracting the feature values ​​of the whitelist functions, such as... Figure 2 As shown, the specific process is as follows: Step S201: Parse the functions in the whitelist file and store the functions in the whitelist into an array for subsequent parsing and processing. In this solution, the whitelist is stored in the compilation project as a configuration file.

[0034] Step S202: Take out one whitelist function from the array one by one.

[0035] Step S203: Determine if the whitelist function is empty. If it is empty, it means the processing has been completed, and the processing flow ends. If it is not empty, proceed to the next step.

[0036] Step S204: Calculate the feature value of the whitelist function. In this scheme, the feature value of the whitelist is calculated by converting the function name, the type of the function's input parameters, the function's return value, the function's source code path, the compilation architecture identifier, the compilation macro configuration, and the dependent file signature into a string. Then, the CRC check value of this string is calculated, and the result is used as the feature value of the function.

[0037] Step S205: Store the calculated feature values ​​and function names in the database for use in compiling the kernel image and driver module later, and return to step S202.

[0038] S104) Compilation and verification.

[0039] When compiling a kernel image or kernel module, functions are sequentially retrieved from an array, and the feature values ​​of the retrieved functions are matched against the stored feature values. If a match is found and the feature values ​​are consistent, the retrieved function is exported and compiled in a unified binary compilation environment. The detailed process includes the following: 1) Kernel Image Compilation Verification: This embodiment modifies the Linux kernel compilation process by adding a feature value verification process for whitelisted functions before the original compilation process. For example... Figure 3 As shown, the specific process is as follows: Step S301: Parse the functions in the whitelist file and store the functions in the whitelist into an array for subsequent parsing and processing. In this embodiment, the whitelist is stored in the compilation project as a configuration file.

[0040] Step S302: Take out one whitelist function from the array one by one.

[0041] Step S303: Determine if the whitelist function is empty. If it is empty, it means the processing is complete, and the processing flow ends. If it is not empty, proceed to the next step.

[0042] Step S304: Calculate the feature value of the whitelist function. In this scheme, the feature value of the whitelist is calculated by converting the function name, the type of the function's input parameters, the function's return value, the function's source code path, the compilation architecture identifier, the compilation macro configuration, and the dependent file signature into a string. Then, the CRC check value of this string is calculated, and the result is used as the feature value of the function and recorded as T1.

[0043] Step S305: Retrieve the feature value of the function corresponding to the whitelist from the database and denote it as T2.

[0044] Step S306: Compare the feature values ​​of T1 and T2. If they are not equal, it indicates that the interface has changed. Print an interface exception and stop compilation. If they are equal, proceed to the next step.

[0045] Step S307: Export this function to the external interface of the kernel image, then jump to step S302.

[0046] 2) Kernel module compilation verification: In this embodiment, the kernel module compilation process is modified by adding a feature value verification process for external functions before the original compilation process. For example... Figure 4 As shown, the specific process is as follows: Step S401: Analyze the external functions used in the module code and store the external functions in an array.

[0047] Step S402: Take one function from the array one by one.

[0048] Step S403: Determine if the retrieved function is empty. If it is empty, the function has been processed, and the processing flow ends. If the retrieved function is not empty, proceed to the next step.

[0049] Step S404: Compare the retrieved function with the whitelist function list to determine if the retrieved function is a whitelist function. If it is not a whitelist function, it means that an external function not on the whitelist is being used, output an error message, and end the process. If it is a whitelist function, proceed to the next step.

[0050] Step S405: Calculate the feature value of the function. In this scheme, the feature value of the function is calculated by converting the function name, the type of the function's input parameters, the function's return value, the function's source code path, the compilation architecture identifier, the compilation macro configuration, and the dependent file signature into a string. Then, the CRC check value of this string is calculated, and the result is used as the feature value of the function and recorded as T1.

[0051] Step S406: Retrieve the feature value of the function corresponding to the whitelist from the database and denote it as T2.

[0052] Step S407: Compare the feature values ​​of T1 and T2. If they are not equal, it indicates that the interface has changed. Print an interface exception and end the process. If they are equal, jump to step S402.

[0053] Through the above steps, this embodiment achieves binary program compatibility between the operating system kernel and kernel modules under the premise of binary separate compilation, ensuring that the kernel modules can be loaded smoothly and function normally after separate compilation.

[0054] Furthermore, this embodiment also proposes a binary compatibility system between Linux kernel images and modules, including interconnected processors and computer-readable storage media, wherein a computer program is stored in the computer-readable storage media, and the computer program is executed by the processor to implement the steps of the binary compatibility method between Linux kernel images and modules described in this embodiment.

[0055] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-readable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0056] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A method for binary compatibility between Linux kernel images and modules, characterized in that, Includes the following steps: Obtain a list of whitelisted functions, calculate and save the feature value of each whitelisted function in the list, wherein the whitelisted functions are functions applied for by the device driver vendor and reviewed by the kernel image vendor; When compiling a kernel image or kernel module, functions are sequentially retrieved from the array, and the feature values ​​of the retrieved functions are matched with the saved feature values. If a match is found and the feature values ​​are consistent, the retrieved function is exported and compiled in a unified binary compilation environment. The unified binary compilation environment encapsulates the compilation environments of kernel images and driver modules into a container, and uses a customized compilation toolchain and the same compilation parameters for the compilation process, thereby ensuring compatibility from the source code level to the binary level.

2. The binary compatibility method between Linux kernel images and modules according to claim 1, characterized in that, When calculating and saving the feature values ​​of each whitelisted function in the list, specifically for the same function, the function name, the type of the function's input parameters, the function's return value, the function's source code path, the compilation architecture identifier, the compilation macro configuration, and the dependent file signature are converted into strings. Then, the CRC check value of the string is calculated as the feature value corresponding to the function, and the feature value of the function is saved along with the function name.

3. The binary compatibility method between Linux kernel images and modules according to claim 1, characterized in that, Before retrieving functions from the array one by one, the process also includes: If a kernel image is compiled, the functions in the whitelist file are parsed and stored in an array; If a kernel module is compiled, the external functions used in the module code are analyzed and stored in an array.

4. The binary compatibility method between Linux kernel images and modules according to claim 3, characterized in that, If a kernel image is compiled, when the feature values ​​of the extracted functions are matched against the saved feature values, this includes: The name of the function to be extracted, the types of the parameters passed to the function, the return value of the function, the source code path of the function, the compilation architecture identifier, the compilation macro configuration, and the dependent file signature are converted into a string. Then, the CRC check value of the string is calculated and used as the feature value T1 of the extracted function. Get the feature value T2 corresponding to the saved function with the same name, and compare the feature value T1 with the feature value T2; If feature value T1 is not equal to feature value T2, an interface exception is indicated and compilation stops; if feature value T1 is equal to feature value T2, the extracted function is exported to the external interface of the kernel image, and then the next function is extracted from the array. The feature value of the extracted function is matched with the saved feature value again, until all functions in the array are extracted.

5. The binary compatibility method between Linux kernel images and modules according to claim 3, characterized in that, If a kernel module is compiled, when the feature values ​​of the extracted function are matched against the saved feature values, this includes: The function to be extracted is compared with the whitelist of functions to determine whether the function to be extracted is a whitelist function. If it is not a whitelist function, an error message is output and the process ends. If it is a whitelist function, the name of the function to be extracted, the type of the parameters passed to the function, the return value of the function, the source code path of the function, the compilation architecture identifier, the compilation macro configuration, and the signature of the dependent files are converted into a string, and then the CRC check value of the string is calculated as the feature value T1 of the extracted function; Get the feature value T2 corresponding to the saved function with the same name, and compare the feature value T1 with the feature value T2; If feature value T1 is not equal to feature value T2, an interface exception is indicated and compilation stops; if feature value T1 is equal to feature value T2, the next function is retrieved from the array, and the feature value of the retrieved function is matched with the saved feature value again, until all functions in the array are retrieved.

6. A binary compatibility system based on Linux kernel images and modules, characterized in that, The method includes an interconnected processor and a computer-readable storage medium storing a computer program, which is executed by the processor to implement the steps of the binary compatibility method between Linux-based kernel images and modules as described in any one of claims 1 to 5.

Images