Method, device and medium for implementing cross-version drivers in the Linux kernel

Abstract

An embodiment of the present invention discloses a method, device, and medium for implementing cross-version drivers in the Linux kernel. The method includes: when initializing a device driver, instantiating function pointers in a newly added structure using a newly added staking eBPF program in the device driver framework in the kernel to point to functions in the structure, where the functions in the structure are new version driver functions implemented in the eBPF program; when a user program accesses the device through a system call and the kernel calls an old version driver function in the file_operations structure of the general character device driver framework, using the eBPF program to perform hook association between the old version driver function and the corresponding new version driver function, so as to intercept the old version driver function and redirect to execute the new version driver function. This avoids compatibility issues of the kernel with respect to driver modules during kernel version evolution.

Description

Technical Field

[0001] The present invention relates to the field of drive technology, and in particular, to a method, device and medium for implementing cross-version drivers of the Linux kernel. Background Art

[0002] With the rapid development of Linux, it is necessary to adapt peripherals of different computer devices to the Linux kernel, including but not limited to graphics cards, network cards, sensors, and FPGA devices. These devices come from different manufacturers, and the drivers of the devices are usually developed and maintained by the manufacturers. When integrating with the Linux kernel, the driver is compiled into a ko file, and the insmod command is used to install the ko file into the system to make it run and drive the corresponding device.

[0003] During the version evolution process of the Linux kernel, structures, unions, functions, etc. defined in the kernel code will inevitably change. Similarly, the definitions of functions will also have changes in parameters, renaming, or disappearance. Therefore, changes in the kernel version will cause the system to report errors when checking the insmod installation of the ko file from the manufacturer. At the same time, there will also be a situation where the installed driver is not compatible with the kernel, affecting the normal operation of the device. Summary of the Invention

[0004] Embodiments of the present invention provide a method, device and medium for implementing cross-version drivers of the Linux kernel to solve the technical problem in the prior art that device drivers cannot be installed and compatible normally due to the version evolution of the Linux kernel.

[0005] In a first aspect, embodiments of the present invention provide a method for implementing cross-version drivers of the Linux kernel, including:

[0006] When initializing the device driver, the newly added staking eBPF program in the device driver framework in the kernel is used to instantiate the function pointer in the newly added file_operations_ext structure to point to the function in the file_operations_ext structure, and the function in the file_operations_ext structure is the new version of the driver function implemented in the eBPF program;

[0007] When the user program accesses the device through a system call and the kernel calls the old version of the driver function in the file_operations structure of the general character device driver framework, the eBPF program is used to perform hook association between the old version of the driver function and the corresponding new version of the driver function, so as to intercept the old version of the driver function and turn to execute the new version of the driver function.

[0008] Second aspect, the embodiment of the present invention further provides a device for implementing cross-version drivers of the Linux kernel, including:

[0009] An instantiation module, configured to, when initializing a device driver, instantiate function pointers in a newly added file_operations_ext structure by using a newly added staking eBPF program in the device driver framework in the kernel, so as to point to functions in the file_operations_ext structure, and the functions in the file_operations_ext structure are new version driver functions implemented in the eBPF program;

[0010] An association module, configured to, when a user program accesses the device through a system call and the kernel calls an old version of a driver function in the file_operations structure of the general character device driver framework, use the eBPF program to perform hook association between the old version of the driver function and the corresponding new version of the driver function, so as to intercept the old version of the driver function and redirect to execute the new version of the driver function.

[0011] Third aspect, the embodiment of the present invention further provides a storage medium containing computer-executable instructions, and the computer-executable instructions are used to execute the method for implementing cross-version drivers of the Linux kernel provided in the above embodiment when executed by a computer processor.

[0012] The method, device and medium for implementing cross-version drivers in the Linux kernel provided by the embodiments of the present invention instantiate function pointers in a newly added file_operations_ext structure by using an inserted eBPF program newly added to the device driver framework in the kernel during device driver initialization, so as to point to the functions in the file_operations_ext structure. The functions in the file_operations_ext structure are new version driver functions implemented in the eBPF program. When a user program accesses the device through a system call and the kernel calls an old version driver function in the file_operations structure of the general character device driver framework, the eBPF program is used to perform hook association between the old version driver function and the corresponding new version driver function, so as to intercept the old version driver function and turn to execute the new version driver function. It is possible to instantiate function pointers in a newly added structure by using an inserted eBPF program newly added to the kernel, corresponding to point to new version driver functions. When the device is called and the old version function in the original file_operations structure in the running kernel is called, the eBPF program is used to hook and associate it to the new version driver function pointed to by the function pointer in the file_operations_ext structure, which can intercept the old version driver function and turn to execute the new version driver function. This avoids the compatibility problem of the kernel with the driver module during the evolution of the kernel version. And it is possible to avoid modifying the kernel, reducing factors affecting security and stability. At the same time, it reduces the maintenance cost of the driver program and there is no need to modify the test driver code following the kernel at any time. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Other features, objects and advantages of the present invention will become more apparent by reading the detailed description of the non-restrictive embodiments with reference to the following drawings:

[0014] Figure 1 It is a schematic flowchart of the method for implementing cross-version drivers in the Linux kernel provided by Embodiment 1 of the present invention;

[0015] Figure 2 It is a schematic flowchart of the method for implementing cross-version drivers in the Linux kernel provided by Embodiment 2 of the present invention;

[0016] Figure 3 It is a schematic structural diagram of the device for implementing cross-version drivers in the Linux kernel provided by Embodiment 3 of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0017] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It can be understood that the specific embodiments described herein are only for explaining the present invention, rather than limiting the present invention. Additionally, it should be noted that for the sake of description, only the parts related to the present invention rather than all the structures are shown in the accompanying drawings.

[0018] Embodiment 1

[0019] Figure 1 FIG. 7 is a flowchart of a method for implementing a Linux kernel cross - version driver provided in Embodiment 1 of the present invention. In this embodiment, according to the evolution of the kernel version, this method can be executed by a Linux kernel cross - version driver implementation device, and specifically includes the following steps:

[0020] Step 110, when initializing the device driver, use the newly added staking eBPF program in the device driver framework in the kernel to instantiate the function pointers in the newly added file_operations_ext structure, so as to point to the functions in the file_operations_ext structure. The functions in the file_operations_ext structure are the new - version driver functions implemented in the eBPF program.

[0021] Due to the evolution of the Linux kernel, changes occur in the kernel. Specifically, the following changes may occur during its evolution: Structures, unions, functions, etc. defined in the code may change. For example, the following structure is defined in the old version:

[0022] struct foo {

[0023] uint32_t a;

[0024] uint32_t b;

[0025] uint16_t c;

[0026] };

[0027] In the evolved new version, it is defined as:

[0028] struct foo {

[0029] uint32_t a;

[0030] uint32_t b;

[0031] uint16_t c;

[0032] Int

[16] d;

[0033] };

[0034] As can be seen from the above, when the Linux kernel evolves from an old version to a new version, the defined structures change.

[0035] In addition, when the Linux kernel evolves from an old version to a new version, the definitions of functions also change in terms of parameters, renaming, or disappearance. For example, the function defined in the old version of the Linux kernel is int foo(void *ctx);

[0036] The corresponding function in the new version is defined as: int foo(void *ctx, int flags). Since there is no backward compatibility mechanism for kernel changes, this will cause the same version of the driver to be incompatible with different versions of the kernel. Therefore, peripheral manufacturers need to modify the driver code at any time following the kernel and add it to the kernel module, which greatly increases the maintenance cost of the driver program.

[0037] In this embodiment, a new structure can be established in advance. The new structure can be named file_operations_ext. The newly added file_operations_ext structure includes:

[0038] A group of function pointers and a corresponding group of new version driver functions. The new version driver functions adaptively modify the parameters according to the modification content of the new version kernel. The new version driver functions can adaptively modify for structure, function, and union changes, and also modify for changes in function names, etc., to adapt to the evolved new kernel and realize the driver function in the new version kernel.

[0039] Correspondingly, an inlined eBPF program can be added to the device driver framework in the new version of the kernel. The device driver framework in Linux realizes the unified management of hardware resources through a layered design, dynamic loading, and event-driven model. The eBPF program can provide highly flexible programmable capabilities for the Linux kernel while ensuring security.

[0040] When initializing the device driver in the kernel, when executing to the inlined eBPF program, the eBPF program can instantiate the function pointers in the newly added structure, that is, modify the function pointers from the original null values to the addresses corresponding to the functions adapted to the new kernel version, facilitating the call of the corresponding new version driver functions.

[0041] Step 120, when the user program accesses the device through a system call and calls an old-version driver function in the file_operations structure of the general character device driver framework during kernel call, the eBPF program is used to perform hook association between the old-version driver function and the corresponding new-version driver function, so as to intercept the old-version driver function and redirect to execute the new-version driver function.

[0042] Since the corresponding device has been registered in the new-version kernel during initialization and a character device node is obtained, when the system kernel remains unchanged, the application program can implement the call to the device through the original file_operations structure open / read / write / close and other driver functions of the general character device driver framework. In this embodiment, this logic is still continued, and the eBPF program is used to perform hook association between the old-version driver function and the corresponding new-version driver function, so as to intercept the old-version driver function and redirect to execute the new-version driver function.

[0043] Exemplarily, the performing hook association between the old-version driver function and the corresponding new-version driver function by using the eBPF program may include: obtaining a pointer to the old-version driver function; filling the hook structure according to the pointer of the instantiated new-version driver function to implement the hook association between the old-version driver function and the corresponding new-version driver function.

[0044] In the file_operations structure, there are also function pointers used to point to the original driver functions. After the kernel version evolves into a new version, to avoid crashes caused by redirecting to the original driver functions, in this embodiment, the eBPF program can be used to point these function pointers to the driver functions in the file_operations_ext structure. The pointer of the read call function running in the file_operations structure can be used as a hook point, and redirected to the function pointer in the instantiated file_operations_ext, and then redirected to execute the new-version driver function.

[0045] Exemplarily, when device functions such as open / read / write are called through the system call, the above method can be used to intercept the driver functions that implement devices such as open / read / write pointed to by the pointer function in the file_operations structure, and redirect to execute the new-version driver functions in the file_operations_ext structure. The original processing logic is intercepted and redirected to the new driver processing logic.

[0046] In this embodiment, the kernel manager can detect the memory and loop logic of the eBPF program when loading and compiling the eBPF program, providing technical guarantees for the security and stability of both the eBPF program and the kernel. When implementing with the above driver, the security of the kernel is ensured.

[0047] In this embodiment, when initializing the device driver, the newly added instrumented eBPF program in the device driver framework in the kernel is used to instantiate the function pointers in the newly added file_operations_ext structure, so as to point to the functions in the file_operations_ext structure implemented in the eBPF program. The functions in the file_operations_ext structure are the new version of the driver functions implemented in the eBPF program. When the user program accesses the device through a system call, when the kernel calls the old version of the driver function in the file_operations structure of the general character device driver framework, the eBPF program is used to hook and associate the old version of the driver function with the corresponding new version of the driver function, so as to intercept the old version of the driver function and turn to execute the new version of the driver function. The newly added instrumented eBPF program in the kernel can be used to instantiate the function pointers in the newly added structure, corresponding to point to the new version of the driver function. When calling the device, when running the old version of the function in the original file_operations structure in the kernel, the eBPF program is used to hook and associate it to the new version of the driver function pointed to by the function pointer in the file_operations_ext structure, which can intercept the old version of the driver function and turn to execute the new version of the driver function. This avoids the compatibility problem of the kernel with the driver module during the evolution of the kernel version. And it is possible to avoid modifying the kernel, reducing the factors affecting security and stability. At the same time, the maintenance cost of the driver program is reduced, and there is no need to modify and test the driver code at any time following the kernel.

[0048] In a preferred implementation manner of this embodiment, the method may further include the following steps: query kernel functions related to the device; add the kernel functions defined as auxiliary functions for accessing kernel functions, so that the new version of the driver function uses the eBPF program to call the kernel functions according to the user program, apply for and release the buffers required by the device, and process the commands and information for device operations. Since the eBPF program cannot directly call kernel functions, the eBPF program cannot directly use the kernel functions and variables of some devices. For example: call the kernel function, apply for and release the buffers required by the device, and process the commands and information for device operations. For example: information such as interrupts. Exemplarily, the function can be defined as the __bpf_kfunc type, and in this embodiment, it may include the following several types: ebpf_request_irq; ebpf_dma_alloc_coherent, which can implement calling the kernel interrupt function and applying for the buffers required by the device.

[0049] Embodiment 2

[0050] Figure 2 FIG. is a schematic flowchart of the Linux kernel cross-version driver implementation method provided in Embodiment 2 of the present invention. This embodiment is optimized based on the above embodiment, and the newly added file_operations_ext structure is specifically optimized as: a group of function pointers, and a corresponding group of new version driver functions pointed to. The new version driver functions are implemented in the eBPF program and are driver functions for upgrading when the kernel remains unchanged. Correspondingly, the method may further include the following steps: when the user program fails to access the device through a system call, unload the loaded eBPF program in the kernel, so that the function pointers in the file_operations_ext structure are 0; re-initialize the device driver again. When the user program accesses the device through a system call, call the old version driver function using the file_operations structure.

[0051] See Figure 2 , the Linux kernel cross-version driver implementation method includes:

[0052] Step 210, when initializing the device driver, instantiate the function pointers in the newly added file_operations_ext structure by using the newly added staking eBPF program in the device driver framework in the kernel, so as to point to the functions in the file_operations_ext structure. The functions are implemented in the eBPF program and are driver functions for upgrading when the kernel remains unchanged.

[0053] Step 220, when the user program accesses the device through a system call and calls the old version of the driver function in the file_operations structure of the general character device driver framework in the kernel, the eBPF program is used to hook-associate the old version of the driver function with the corresponding new version of the driver function, so as to intercept the old version of the driver function and turn to execute the new version of the driver function.

[0054] Step 230, when the user program fails to access the device through a system call, unload the loaded eBPF program in the kernel so that the function pointer in the file_operations_ext structure is 0.

[0055] In this embodiment, the above method can be used to upgrade the device driver when the kernel has not evolved. However, the upgraded driver may have problems. Therefore, a rollback operation needs to be performed on it to make the driver return to the version before the upgrade to ensure that the device can be used normally.

[0056] When the user program fails to access the device through a system call, it can be determined that there is an exception in the new version of the driver function. Therefore, in this embodiment, the eBPF program in the kernel can be unloaded. Exemplarily, the ID of the eBPF program in the kernel can be queried, and then the eBPF program can be removed according to the ID to execute the original device driver logic.

[0057] Step 240, re-initialize the device driver again. When the user program accesses the device through a system call, call the old version of the driver function using the file_operations structure.

[0058] When re-initializing the device driver again, since the eBPF program has been removed, the function pointers in the newly added file_operations_ext structure are not initialized, so they are all the initial value 0.

[0059] When the user program accesses the device through a system call, since the removal of the eBPF program makes the function pointers in the file_operations_ext structure the initial value, the original hook function becomes invalid, and the original driver function pointed to by the function pointer in the file_operations structure is still executed. That is, it is executed according to the original device driver logic. Using this method, the newly added driver function can be skipped to avoid errors and achieve the rollback of the original driver. Ensure the normal operation of the device in the system.

[0060] In this embodiment, the newly added `file_operations_ext` structure is specifically optimized as: a set of function pointers and a corresponding set of new version driver functions they point to. The new version driver functions are implemented in the eBPF program and are used to upgrade the driver functions without changing the kernel. Correspondingly, the method may further include the following steps: when the user program fails to access the device through a system call, unload the loaded eBPF program in the kernel so that the function pointers in the `file_operations_ext` structure are set to 0; then re-initialize the device driver. When the user program accesses the device through a system call, use the `file_operations` structure to call the old version driver functions. By using the above method, when there are problems with the new version driver without changing the kernel, it is possible to roll back to the old version driver that could be used normally before, without the need to perform a large number of operations on the device driver again, reducing the difficulty and workload of driver rollback.

[0061] In a preferred embodiment of this embodiment, the method may further include the following steps: when the eBPF program is loaded into the kernel, use the JIT compiler to convert it into instructions matching the hardware architecture; use a verification tool to perform static analysis on the eBPF program, and use abstract interpretation technology to simulate the program execution path to ensure the security and correctness of the eBPF program; use a compiler to compile the statically analyzed eBPF program into eBPF program bytecode. The compatibility problem caused by differences in data structures and symbols between different kernel versions can be solved through the CO-RE technology of eBPF. Embedding metadata describing the kernel data structure at the compilation stage enables the same eBPF code to run adaptively on multiple kernel versions. Further, the eBPF program bytecode can be copied and transplanted into the Linux kernel of other terminals, further reducing the difficulty of using the Linux kernel cross-version driver implementation method.

[0062] Embodiment III

[0063] Figure 3 is a schematic structural diagram of the Linux kernel cross-version driver implementation device provided in Embodiment III of the present invention. Refer to Figure 3 The Linux kernel cross-version driver implementation device includes:

[0064] An instantiation module 310, configured to instantiate the function pointers in the newly added `file_operations_ext` structure by using the newly added stitched eBPF program in the device driver framework in the kernel during device driver initialization, so as to point to the functions in the `file_operations_ext` structure. The functions in the `file_operations_ext` structure are new version driver functions implemented in the eBPF program.

[0065] An association module 320, configured to, when a user program accesses the device through a system call and an old version of a driver function is called in the file_operations structure of the general character device driver framework during kernel call, use the eBPF program to perform hook association between the old version of the driver function and the corresponding new version of the driver function, so as to intercept the old version of the driver function and turn to execute the new version of the driver function.

[0066] The Linux kernel cross-version driver implementation device provided in this embodiment, by instantiating a function pointer in a newly added staking eBPF program in the device driver framework in the kernel during device driver initialization to point to a function in the file_operations_ext structure, where the function in the file_operations_ext structure is a new version of the driver function implemented in the eBPF program; when a user program accesses the device through a system call and an old version of a driver function is called in the file_operations structure of the general character device driver framework during kernel call, use the eBPF program to perform hook association between the old version of the driver function and the corresponding new version of the driver function, so as to intercept the old version of the driver function and turn to execute the new version of the driver function. The newly added staking eBPF program in the kernel can be used to instantiate the function pointer in the newly added structure to correspondingly point to the new version of the driver function. When the device is called and the old version function in the original file_operations structure in the running kernel is called, the eBPF program hook is associated with the new version of the driver function pointed to by the function pointer in the file_operations_ext structure, which can intercept the old version of the driver function and turn to execute the new version of the driver function. This avoids the compatibility problem of the kernel with the driver module during kernel version evolution. And it can reduce the factors affecting security and stability without modifying the kernel. At the same time, it reduces the maintenance cost of the driver program and does not need to modify and test the driver code following the kernel at any time.

[0067] Based on the above embodiments, the association module includes:

[0068] An acquisition unit, configured to acquire a pointer to the old version of the driver function;

[0069] A filling unit, configured to fill the hook structure according to the pointer to the instantiated new version of the driver function, so as to implement hook association between the old version of the driver function and the corresponding new version of the driver function.

[0070] Based on the above embodiments, the device further includes:

[0071] A query module for querying kernel functions related to a device;

[0072] An addition module for adding the kernel function defined as an auxiliary function for accessing kernel functions, so that a new version of the driver function uses an eBPF program to call the kernel function according to a user program, apply for and release buffers required by the device, and process commands and information for device operations.

[0073] Based on the above embodiments, the newly added file_operations_ext structure includes:

[0074] A set of function pointers and a corresponding set of new version driver functions, and the new version driver functions adaptively modify parameters for the modified content of the new version kernel.

[0075] Based on the above embodiments, the newly added file_operations_ext structure includes:

[0076] A set of function pointers and a corresponding set of new version driver functions pointed to, and the new version driver functions are implemented in an eBPF program and are driver functions for upgrading when the kernel remains unchanged.

[0077] Based on the above embodiments, the device further includes:

[0078] An uninstallation module for uninstalling the loaded eBPF program in the kernel when a user program fails to access the device through a system call, so that the function pointers in the file_operations_ext structure are 0;

[0079] A call module for re-initializing device drivers again, and when a user program accesses the device through a system call, using the file_operations structure to call an old version of the driver function.

[0080] Based on the above embodiments, the device further includes:

[0081] When the eBPF program is loaded into the kernel, using a JIT compiler to convert it into instructions matching the hardware architecture;

[0082] Using a verification tool to perform static analysis on the eBPF program, and using abstract interpretation technology to simulate the program execution path to ensure the security and correctness of the eBPF program;

[0083] Using a compiler to compile the statically analyzed eBPF program into eBPF program bytecode.

[0084] Based on the above embodiments, the device further includes:

[0085] A replication module for replicating and transplanting the eBPF program bytecode into the Linux kernel of other terminals.

[0086] The Linux kernel cross-version driver implementation device provided by the embodiments of the present invention can execute the Linux kernel cross-version driver implementation method provided by any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0087] Embodiment 4

[0088] Embodiment 4 of the present invention also provides a storage medium containing computer-executable instructions, and the computer-executable instructions are used to execute any of the Linux kernel cross-version driver implementation methods provided by the above embodiments when executed by a computer processor.

[0089] The computer storage medium of the embodiments of the present invention can be any combination of one or more computer-readable media. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. The 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 of the above. More specific examples (non-exhaustive list) of the computer-readable storage medium include: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this document, the computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0090] The computer-readable signal medium can include a data signal propagated in a baseband or as part of a carrier wave, which carries the computer-readable program code. Such a propagated data signal can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. The computer-readable signal medium can also be any computer-readable medium other than the computer-readable storage medium, and this computer-readable medium can send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0091] The program code contained on the computer-readable medium can be transmitted by any suitable medium, including but not limited to wireless, wire, optical cable, RF, etc., or any suitable combination of the above.

[0092] Computer program code for performing the operations of the present invention may be written in one or more programming languages or combinations thereof, including object-oriented programming languages such as Java, Smalltalk, C++, and also including conventional procedural programming languages such as the "C" language or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, executed as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or device. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0093] Note that the above is only a preferred embodiment of the present invention and the technical principles applied. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, re-adjustments, and substitutions can be made by those skilled in the art without departing from the protection scope of the present invention. Therefore, although the present invention has been described in more detail through the above embodiments, the present invention is not limited to the above embodiments. Without departing from the concept of the present invention, more other equivalent embodiments may be included, and the scope of the present invention is determined by the scope of the appended claims.

Claims

1. A method for implementing cross-version drivers in the Linux kernel, characterized in that Comprising: During device driver initialization, use the newly added instrumentation eBPF program in the device driver framework in the kernel to instantiate the function pointers in the newly added file_operations_ext structure to point to the functions in the file_operations_ext structure, and the functions in the file_operations_ext structure are the new version of the driver functions implemented in the eBPF program; When the user program accesses the device through a system call and calls the old version of the driver function in the file_operations structure of the kernel general character device driver framework, use the eBPF program to perform hook association between the old version of the driver function and the corresponding new version of the driver function, so as to intercept the old version of the driver function and turn to execute the new version of the driver function.

2. The method according to claim 1, wherein The using the eBPF program to perform hook association between the old version of the driver function and the corresponding new version of the driver function includes: Obtain the pointer of the old version of the driver function; Fill the hook structure according to the pointer of the instantiated new version of the driver function to achieve hook association between the old version of the driver function and the corresponding new version of the driver function.

3. The method according to claim 1, wherein The method further includes: Query the kernel functions related to the device; Add the kernel functions defined as auxiliary functions for accessing kernel functions, so that the new version of the driver function uses the eBPF program to apply for and release the buffers required by the device and process the commands and information for device operations according to the user program's call of the kernel functions.

4. The method according to claim 1, characterized in that The newly added file_operations_ext structure includes: A group of function pointers and a corresponding group of new version of the driver functions, and the new version of the driver functions adaptively modify the parameters according to the modified content of the new version of the kernel.

5. The method according to claim 1, wherein The newly added file_operations_ext structure includes: A group of function pointers and a corresponding group of new version of the driver functions they point to, and the new version of the driver functions are implemented in the eBPF program and are the upgraded driver functions when the kernel remains unchanged.

6. The method according to claim 5, wherein The method further includes: When the user program fails to access the device through a system call, unload the loaded eBPF program in the kernel so that the function pointers in the file_operations_ext structure are 0; Re-initialize the device driver again. When the user program accesses the device through a system call, use the file_operations structure to call the old version of the driver function.

7. The method according to claim 1, characterized in that, The method further includes: When the eBPF program is loaded into the kernel, use the JIT compiler to convert it into instructions matching the hardware architecture; Use the verification tool to perform static analysis on the eBPF program, and use the abstract interpretation technology to simulate the program execution path to ensure the security and correctness of the eBPF program; Use the compiler to compile the statically analyzed eBPF program into eBPF program bytecode.

8. The method according to claim 7, characterized in that, The method further includes: Copy and transplant the eBPF program bytecode to the Linux kernel of other terminals.

9. A device for implementing cross-version drivers of the Linux kernel, characterized in that, Comprising: An instantiation module, which is used to instantiate function pointers in a newly added file_operations_ext structure by using an inserted eBPF program newly added to the device driver framework in the kernel during device driver initialization, so as to point to functions in the file_operations_ext structure, and the functions in the file_operations_ext structure are new versions of driver functions implemented in the eBPF program; An association module, which is used to hook and associate an old version of a driver function with a corresponding new version of the driver function by using the eBPF program when a user program accesses the device through a system call and calls the old version of the driver function in the file_operations structure of the kernel general character device driver framework, so as to intercept the old version of the driver function and turn to execute the new version of the driver function.

10. A storage medium containing computer-executable instructions, characterized in that, The computer-executable instructions, when executed by a computer processor, are used to execute the Linux kernel cross-version driver implementation method according to any one of claims 1-8.

Images