A linux kernel module cross-version binary compatibility method

Abstract

This invention relates to a method for cross-version binary compatibility of Linux kernel modules, belonging to the field of computer operating system kernels. It includes the following steps: During the compilation phase, the compiler identifies specific keywords (__kabi_reloc_member, __kabi_check_member, __kabi_sizeof) and records instruction offsets, type identifiers, member variable name offsets, and relocation types, generating a .kabi_relocs segment. During the loading phase, the loader parses the .kabi_relocs segment, combines it with module BTF and kernel BTF information, and dynamically repairs instructions based on the relocation type. This invention achieves "compile once, run anywhere" binary compatibility for kernel modules, with the repair operation completed at load time, having no impact on runtime performance.

Description

Technical Field

[0001] This invention relates to the field of computer operating system kernels, and in particular to a method for cross-version binary compatibility of Linux kernel modules. Background Technology

[0002] The kernel KABI is unstable; kernel version upgrades inevitably cause KABI changes, resulting in third-party driver module .ko files becoming uninstallable in the new kernel. This necessitates compiling a corresponding .ko version for each kernel version, making binary compatibility impossible. Even if the driver's functionality remains unchanged, recompilation is required. If the driver is not open source, it's necessary to urge third-party vendors to provide new .deb packages.

[0003] Therefore, there is an urgent need for a method to achieve cross-version binary compatibility of Linux kernel modules, which can adapt to different kernel versions while keeping the driver functionality unchanged. Summary of the Invention

[0004] To address the issue of ensuring driver functionality remains unchanged while enabling compatibility with different kernel versions, this invention provides a method for cross-version binary compatibility of Linux kernel modules.

[0005] In a first aspect of the invention, a method for cross-version binary compatibility of Linux kernel modules is provided. The method includes: During the compilation phase, keywords are added to the compiler and modified via the command line. These keywords include __kabi_reloc_member, __kabi_check_member, and __kabi_sizeof. When a keyword is detected, the offset address of the instruction corresponding to the modified code, the type identifier of the accessed type, the offset of the member variable name in the string subfield, and the relocation type are recorded and stored in the .kabi_relocs segment designed specifically for KABI adaptation, forming a relocation record; During the loading phase, the relocation records in the .kabi_relocs segment are parsed, and the module BTF information at compile time and the kernel BTF information at runtime are combined to locate the instruction to be repaired and its corresponding kernel type. By comparing the differences in memory layout between the same kernel type at compile time and runtime, the instructions to be repaired are dynamically corrected according to the relocation type.

[0006] Optionally, the relocation record includes the following fields; Instruction offset field: 32-bit integer, used to represent the offset value of the instruction to be repaired relative to the start address of the code segment; Type identifier field: 32-bit integer, used to obtain type memory layout information from BTF information; Relocation type field: 32-bit integer, used to identify whether the relocation type is offset repair type, member detection type, or size detection type; Member variable name offset field: 32-bit integer, used to represent the offset of the member name string in the .kabi_relocs string subfield. This field is invalid when the relocation type is size probe type.

[0007] Optionally, the correspondence between the keywords and relocation types is as follows: The __kabi_reloc_member is used to modify the access operation of the structure member. It is an offset repair type record generated in the .kabi_relocs section, which instructs the loader to correct the memory access offset caused by the change of member position. The __kabi_check_member is used to check whether a certain member of a structure exists. It receives two parameters: a pointer to a structure variable and the member name. It generates a member probe type record in the .kabi_relocs section and instructs the loader to directly inline the result of the conditional judgment into the instruction. The __kabi_sizeof is used to obtain the size of the structure type in the current kernel. A size probe type record is generated in the .kabi_relocs section, which instructs the loader to replace the immediate value in the instruction with the actual structure size in the current kernel.

[0008] Optionally, the BTF information can be obtained in the following ways: Kernel BTF information is read through the / sys / kernel / btf / vmlinux file node; Module BTF information is recorded in the .BTF section of the .ko file; Obtain compile-time type memory layout information by parsing the .BTF segment; Runtime type memory layout information is obtained by reading nodes.

[0009] Optionally, the step of dynamically correcting the instructions to be repaired based on the relocation type by comparing the differences in memory layout at compile time and runtime for the same type includes: The virtual address in memory of the instruction to be repaired is calculated based on the instruction offset in the relocation record and the module load base address; Read the raw machine instruction at the virtual address and decode its instruction type and operand encoding method according to the instruction set architecture; Execute the corresponding repair logic to calculate new operands based on the relocation type; The calculated new operands are written back to the corresponding instruction operand field according to the instruction encoding format to complete the instruction repair.

[0010] Optionally, based on the relocation type, perform the corresponding repair logic to calculate new operands, including; When the relocation type is offset repair type, the type name in the module BTF information is obtained through the type identifier in the relocation record. Then, the corresponding runtime type memory layout information in the kernel BTF information is found through the type name. The offset value of the member variable is found through the member variable name in the corresponding runtime type memory layout information in the kernel BTF information. Finally, the offsets of the structure member variables in the module BTF information and the kernel BTF information are compared. If they are the same, no repair is needed. If they are different, the new address of the member variable, i.e. the new operand, can be calculated by adding the original address of the structure variable to the offset of the structure member in the kernel.

[0011] Optionally, the relocation type performs corresponding repair logic to calculate new operands, including: When the relocation type is a member probe type, the type name in the module BTF information is obtained through the type identifier in the relocation record. Then, the corresponding runtime type memory layout information in the kernel BTF information is found through the type name. Then, the member variable name string is obtained from the string through the member variable name offset in the relocation record. The member variable name is searched for in the type through the member variable name in the corresponding runtime type memory layout information in the kernel BTF information. If it exists, the new operand is true; if it does not exist, the new operand is false.

[0012] Optionally, the relocation type performs corresponding repair logic to calculate new operands, including: When the relocation type is size probe type, the type name in the module BTF information is obtained through the type identifier in the relocation record. Then, the corresponding runtime type memory layout information in the kernel BTF information is found through the type name. Then, the member variable name string is obtained from the string through the member variable name offset in the relocation record. The size of the structure in the kernel, i.e. the new operand, can be obtained from the corresponding runtime type memory layout information in the kernel BTF information.

[0013] Optionally, the module load base address is the starting address of the memory region allocated by the kernel for storing copying of module files, and the virtual address is calculated by adding the instruction offset to the module load base address.

[0014] Optionally, the method is applicable to the following scenarios caused by changes in kernel data structures: changes in member offsets, changes in type and size, and member deletion.

[0015] In summary, the present invention has at least one of the following beneficial technical effects: 1. The driver only needs to be compiled once and can run on different kernel versions without recompiling or modifying the source code; 2. All repair operations are completed during the loading phase, with no additional overhead during driver runtime; 3. Accurate memory layout difference calculations are performed based on BTF information to ensure the accuracy of the repair; 4. Supports various KABI change scenarios, such as changes in structure member offset, addition or deletion of members, and changes in type and size. Detailed Implementation

[0016] The present invention will now be described in further detail.

[0017] This specific embodiment is merely an explanation of the present invention and is not intended to limit the invention. After reading this specification, those skilled in the art can make modifications to this embodiment without contributing any inventive step, but such modifications are protected by patent law as long as they fall within the scope of the claims of the present invention.

[0018] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below in conjunction with 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 are within the scope of protection of the present invention.

[0019] The following are explanations of the relevant technical terms involved in this invention: BTF: A compact metadata format for describing programs and data structures, capable of fully recording the layout information of types in memory.

[0020] KABI: Kernel Application Binary Interface ko file (kernel object file): The purpose of this file is to move some kernel functions outside the kernel, insert them into the kernel when needed, and unload them when not needed.

[0021] Relocation: The process of mapping the addresses of program code, data, or symbols from one logical address space to another physical or virtual address space.

[0022] This invention proposes a method for cross-version binary compatibility of Linux kernel modules. The core of this method is that the driver only needs to be compiled once to run across kernel versions. When the KABI changes, the loader can dynamically repair erroneous instructions to adapt to the currently running kernel. Furthermore, this dynamic repair is completed during loading, without impacting the performance of the driver during runtime.

[0023] This invention comprises two phases: a compilation phase and a loading phase, wherein: During the compilation phase, the compiler is extended with metadata injection.

[0024] Specifically, to achieve driver compatibility across different kernel versions, this invention first extends the functionality of the GCC / Clang compiler by adding new keywords. These keywords generate a completely new segment during compilation, named the `.kabi_relocs` segment. Each piece of code modified by these keywords will generate a record in the `.kabi_relocs` segment, with different keywords corresponding to different record types. It's important to know that the keywords include `__kabi_reloc_member`, `__kabi_check_member`, and `__kabi_sizeof`. The `.kabi_relocs` segment is specifically designed for kernel ABI (KABI) adaptation.

[0025] Among them, `kabi_reloc_member` is used to modify the code for accessing structure members, generating an offset repair type record in the `.kabi_relocs` section; `__kabi_check_member` is used to check if a certain member of a structure exists. This keyword modifies two parameters: the first parameter is a pointer to the structure variable, and the second parameter is the name of the member to be checked, generating a member probe type record in the `.kabi_relocs` section; `__kabi_sizeof` is used to modify the structure type name, which can obtain the size of the corresponding structure in the kernel, generating a size probe type record in the `.kabi_relocs` section.

[0026] During the code writing phase, you can use the corresponding keywords to decorate the locations where the above functions are needed. For example: struct s a; int b = __kabi_reloc_member(a->b); / / Creates a record in the .kabi_relocs section, of type offset repair.

[0027] if(__kabi_check_member(a, c)) / / In the .kabi_relocs section, generate a record of type member probe.

[0028] ; / / Logic regarding the existence of member variable c else ; / / Logic for member variable c not existing int size = __kabi_sizeof(struct s); / / Creates a call record in the .kabi_relocs segment, of type size probe.

[0029] These keywords do not change the original semantics of the program; their purpose is to provide the compiler with high-level intent descriptions, acting as meta-information annotations during compilation.

[0030] During compilation, when the compiler recognizes these keywords, it generates specific relocation records. Each record contains instruction offsets, type identifiers, member variable name offsets, and relocation types. All this information is stored in a completely new segment (.kabi_relocs) specifically designed for kernel ABI (KABI) adaptation. The relocation record table is shown below; Relocation record table ,

[0031] The relocation type directly corresponds to the three capabilities supported at compile time, and it explicitly tells future module loaders what kind of repair operation should be performed: __kabi_reloc_member: This corresponds to offset repair capability, indicating that the loader needs to correct memory access offsets caused by changes in member positions.

[0032] __kabi_check_member: corresponds to the existence detection capability, instructing the loader to directly inline the result of the condition check (true or false) into the instruction.

[0033] __kabi_sizeof: corresponds to size detection capability, instructing the loader to replace the immediate value in the instruction with the actual structure size in the current kernel.

[0034] During the loading phase, the relocation records in the .kabi_relocs segment are parsed, and the module BTF information at compile time and the kernel BTF information at runtime are combined to locate the instruction to be repaired and its corresponding kernel type. By comparing the differences in memory layout between compile time and runtime for the same kernel type, the instruction to be repaired is dynamically corrected according to the relocation type.

[0035] Specifically, when the insmod command is used to load the driver module, the system calls the loader provided by the invention. The loader reads the .kabi_relocs section in the ko file, parses the relocation records one by one, and then obtains the module BTF information from the .BTF section of the ko file, thereby obtaining the type memory layout information at compile time. It also obtains the kernel BTF information from the / sys / kernel / btf / vmlinux file node, thereby obtaining the type memory layout information at runtime.

[0036] The virtual address of the instruction to be repaired in memory is calculated based on the instruction offset and module load base address in the relocation record; the original machine instruction at that virtual address is read, and its instruction type and operand encoding method are decoded according to the instruction set architecture; the corresponding repair logic is executed according to the relocation type to calculate the new operand; the calculated new operand is written back to the corresponding instruction operand segment according to the instruction encoding format to complete the instruction repair.

[0037] The calculation of new operands based on the corresponding repair logic according to the relocation type includes: When the relocation type is offset repair type, the operand is a memory address. The loader obtains the type name from the module BTF information through the type identifier in the relocation record. Then, it finds the corresponding runtime type memory layout information in the kernel BTF information through the type name. Next, it obtains the string character of the member variable name from the string through the member variable name offset in the relocation record. It finds the offset value of the member variable through the member variable name in the corresponding runtime type memory layout information in the kernel BTF information. Finally, it compares the offsets of the structure member variables in the module BTF information and the kernel BTF information. If they are the same, no repair is needed. If they are different, the new address of the member variable, i.e., the new operand, can be calculated by adding the original structure variable address to the offset of the structure member in the kernel.

[0038] When the relocation type is a member probe type, the operand is an immediate value representing true or false. The loader obtains the type name from the module's BTF information through the type identifier in the relocation record, then finds the corresponding runtime type memory layout information in the kernel BTF information through the type name, and then obtains the string character of the member variable name from the string through the member variable name offset in the relocation record. It then searches for the existence of this member in the type through the member variable name in the corresponding runtime type memory layout information in the kernel BTF information. If it exists, the new operand is true; if it does not exist, the new operand is false.

[0039] When the relocation type is size probe type, the operand is an immediate value. The loader obtains the type name in the module BTF information through the type identifier in the relocation record, and then finds the corresponding runtime type memory layout information in the kernel BTF information through the type name. From the corresponding runtime type memory layout information in the kernel BTF information, the size of the structure in the kernel can be obtained, i.e., the new operand.

[0040] This invention, through the collaborative design of "compiler injection of meta-information" and "loader runtime repair," enables driver modules compiled for specific kernel versions to be safely and automatically adapted to run on other kernel versions. It effectively solves the module compatibility problem caused by changes in kernel data structures and provides basic support for achieving "compile once, run anywhere" kernel drivers.

[0041] The above description is merely a preferred embodiment of the present invention and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this invention is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the foregoing disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this invention.

Claims

1. A method for cross-version binary compatibility of Linux kernel modules, characterized in that, include: During the compilation phase, keywords are added to the compiler and modified via the command line. These keywords include __kabi_reloc_member, __kabi_check_member, and __kabi_sizeof. When a keyword is detected, the offset address of the instruction corresponding to the modified code, the type identifier of the accessed type, the offset of the member variable name in the string subfield, and the relocation type are recorded and stored in the .kabi_relocs segment designed specifically for KABI adaptation, forming a relocation record; During the loading phase, the relocation records in the .kabi_relocs segment are parsed, and the module BTF information at compile time and the kernel BTF information at runtime are combined to locate the instruction to be repaired and its corresponding kernel type. By comparing the differences in memory layout between the same kernel type at compile time and runtime, the instructions to be repaired are dynamically corrected according to the relocation type.

2. The method for cross-version binary compatibility of Linux kernel modules according to claim 1, characterized in that, The relocation record includes the following fields; Instruction offset field: 32-bit integer, used to represent the offset value of the instruction to be repaired relative to the start address of the code segment; Type identifier field: 32-bit integer, used to obtain type memory layout information from BTF information; Relocation type field: 32-bit integer, used to identify whether the relocation type is offset repair type, member detection type, or size detection type; Member variable name offset field: 32-bit integer, used to represent the offset of the member name string in the .kabi_relocs string subfield. This field is invalid when the relocation type is size probe type.

3. A method for cross-version binary compatibility of Linux kernel modules according to claim 2, characterized in that, The correspondence between the keywords and relocation types is as follows: The __kabi_reloc_member is used to modify the access operation of the structure member. It is an offset repair type record generated in the .kabi_relocs section, which instructs the loader to correct the memory access offset caused by the change of member position. The __kabi_check_member is used to check whether a certain member of a structure exists. It receives two parameters: a pointer to a structure variable and the member name. It generates a member probe type record in the .kabi_relocs section and instructs the loader to directly inline the result of the condition check into the instruction. The __kabi_sizeof is used to obtain the size of the structure type in the current kernel. A size probe record is generated in the .kabi_relocs section, which instructs the loader to replace the immediate value in the instruction with the actual structure size in the current kernel.

4. A method for cross-version binary compatibility of Linux kernel modules according to claim 2, characterized in that, The methods for obtaining the BTF information include: Kernel BTF information is read through the / sys / kernel / btf / vmlinux file node; Module BTF information is recorded in the .BTF section of the .ko file; Obtain compile-time type memory layout information by parsing the .BTF segment; Runtime type memory layout information is obtained by reading nodes.

5. A method for cross-version binary compatibility of Linux kernel modules according to claim 4, characterized in that, The method of dynamically correcting the instructions to be repaired based on the relocation type by comparing the differences in memory layout at compile time and runtime for the same type includes: The virtual address in memory of the instruction to be repaired is calculated based on the instruction offset in the relocation record and the module load base address; Read the raw machine instruction at the virtual address and decode its instruction type and operand encoding method according to the instruction set architecture; Execute the corresponding repair logic to calculate new operands based on the relocation type; The calculated new operands are written back to the corresponding instruction operand field according to the instruction encoding format to complete the instruction repair.

6. A method for cross-version binary compatibility of Linux kernel modules according to claim 5, characterized in that, Execute the corresponding repair logic based on the relocation type to calculate new operands, including: When the relocation type is offset repair, the type name in the module BTF information is obtained through the type identifier in the relocation record. Then, the corresponding runtime type memory layout information in the kernel BTF information is found through the type name. Next, the string character of the member variable name is obtained from the string through the member variable name offset in the relocation record. The offset value of the member variable is found through the member variable name in the corresponding runtime type memory layout information in the kernel BTF information. Finally, the offsets of the structure member variables in the module BTF information and the kernel BTF information are compared. If they are the same, no repair is needed. If they are different, the new address of the member variable, i.e., the new operand, can be calculated by adding the original address of the structure variable to the offset of the structure member in the kernel.

7. A method for cross-version binary compatibility of Linux kernel modules according to claim 5, characterized in that, The relocation type executes corresponding repair logic to calculate new operands, including: When the relocation type is a member probe type, the type name in the module BTF information is obtained through the type identifier in the relocation record. Then, the corresponding runtime type memory layout information in the kernel BTF information is found through the type name. Then, the member variable name string is obtained from the string through the member variable name offset in the relocation record. The member variable name is searched for in the type through the member variable name in the corresponding runtime type memory layout information in the kernel BTF information. If it exists, the new operand is true; if it does not exist, the new operand is false.

8. A method for cross-version binary compatibility of Linux kernel modules according to claim 5, characterized in that, The relocation type executes corresponding repair logic to calculate new operands, including: When the relocation type is size probe type, the type name in the module BTF information is obtained through the type identifier in the relocation record. Then, the corresponding runtime type memory layout information in the kernel BTF information is found through the type name. The size of the structure in the kernel, i.e. the new operand, can be obtained from the corresponding runtime type memory layout information in the kernel BTF information.

9. A method for cross-version binary compatibility of Linux kernel modules according to claim 5, characterized in that, The module load base address is the starting address of the memory region allocated by the kernel for storing copying of module files. The virtual address is calculated by adding the instruction offset to the module load base address.

10. A method for cross-version binary compatibility of Linux kernel modules according to claim 1, characterized in that, The method is applicable to the following scenarios caused by changes in kernel data structures: changes in member offsets, changes in type and size, and member deletion.

Images