Kernel driver test method, device and equipment and readable storage medium

Abstract

The embodiment of the invention provides a kernel driver testing method and device, electronic equipment and a computer readable storage medium. The method specifically comprises the steps of obtaining a first mirror image file, a second mirror image file and first version parameters of a kernel and a driver input by a user; the first mirror image file is a mirror image file of a test environment container obtained after the test environment is subjected to containerization packaging; the test environment is a running environment of a test tool when the kernel driver is tested; the second mirror image file is a mirror image file of a container corresponding to the to-be-tested equipment, and the kernel driver runs in the to-be-tested equipment; when the first version parameter is inconsistent with the kernel driver version parameter in the second mirror image file, generating a target kernel driver according to the first version parameter, and switching the kernel driver corresponding to the to-be-tested device into the target kernel driver; and according to the first mirror image file and the target kernel driver, testing the to-be-tested device to obtain a test result. The test efficiency of the kernel driver can be improved.

Description

Technical Field

[0001] This application relates to the field of network security technology, and in particular to a kernel-driven testing method, apparatus, electronic device, and computer-readable storage medium. Background Technology

[0002] As modern operating systems become increasingly complex, the security and stability of kernel drivers have become paramount. Fuzzing, as an automated software testing technique, can detect potential defects and security vulnerabilities in kernel drivers by randomly mutating the input data.

[0003] In related technologies, when performing fuzz testing on kernel drivers, the test environment can be set up manually, including compiling a specified version of the kernel, compiling the driver to be tested, configuring a virtual machine environment, etc., and then running a fuzz testing tool to perform fuzz testing.

[0004] However, the methods for fuzzing the kernel driver of the operating system in related technologies require manually setting up a test environment for testing. Furthermore, when switching between different versions of the kernel driver during the testing process, the test environment needs to be rebuilt, which consumes a lot of resources and time, resulting in low testing efficiency.

[0005] Application content This application provides a kernel driver testing method, apparatus, electronic device, and computer-readable storage medium, which can reduce the resources and time consumed in kernel driver testing and improve the testing efficiency of kernel drivers.

[0006] Firstly, this application provides a method for testing kernel drivers, the method comprising: Obtain a first image file, a second image file, and test requirements; the first image file is an image file of a container of the test environment obtained by containerizing and encapsulating the test environment; the test environment is the runtime environment of the test tool when testing the kernel driver; the second image file is an image file of a container corresponding to the device under test, and the kernel driver runs in the device under test; the test requirements are used to indicate the test intent for the device under test; If the kernel driver in the second image file does not match the test requirements, a target kernel driver that matches the test requirements is generated according to the test requirements, and the kernel driver corresponding to the device under test is switched to the target kernel driver. Based on the first image file and the target kernel driver, the device under test is tested to obtain the test results.

[0007] Secondly, this application provides a kernel driver testing device, the device comprising: The acquisition module is used to acquire a first image file, a second image file, and test requirements; the first image file is an image file of a container of the test environment obtained by containerizing and encapsulating the test environment; the test environment is the runtime environment of the test tool when testing the kernel driver; the second image file is an image file of a container corresponding to the device under test, and the kernel driver runs in the device under test; the test requirements are used to indicate the test intent for the device under test; The switching module is used to generate a target kernel driver that matches the test requirements when the kernel driver in the second image file does not match the test requirements, and to switch the kernel driver corresponding to the device under test to the target kernel driver. The testing module is used to test the device under test based on the first image file and the target kernel driver, and obtain the test results of the device under test.

[0008] Thirdly, this application provides an electronic device including a memory and one or more programs, wherein one or more programs are stored in the memory and configured to be executed by one or more processors as described above, using a kernel-driven test method.

[0009] Fourthly, this application provides a readable storage medium that, when the instructions in the storage medium are executed by the processor of an electronic device, enables the electronic device to perform the kernel-driven test method described above.

[0010] The embodiments of this application have the following advantages: This embodiment first obtains a first image file, a second image file, and test requirements. The first image file is defined as an image file of a containerized test environment, where the test environment is the runtime environment of the test tool when testing the kernel driver. The second image file is an image file of a container corresponding to the device under test (DUT), where the kernel driver runs. The test requirements indicate the testing intent for the DUT. This makes the first and second image files equivalent to pre-built standardized test templates, eliminating the need to start from scratch for each test. Testing can be performed simply by starting the container according to the test requirements, significantly shortening preparation time and improving testing efficiency. Secondly, if the kernel driver in the second image file does not match the test requirements, a target kernel driver is generated based on the test requirements, and the kernel driver corresponding to the DUT is switched to the target kernel driver. Finally, the DUT is tested based on the first image file and the target kernel driver to obtain the test results. The system can generate the target kernel driver that the user needs to test based on the test requirements, and switch the kernel driver directly within the container of the device under test. This eliminates the need to rebuild the entire test environment, reduces the resources consumed in the test process, and ensures that the switching process will not affect other environments. It only occupies the limited resources within the container, further improving test efficiency and enhancing the flexibility of kernel driver testing. Attached Figure Description

[0011] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a flowchart illustrating the steps of a kernel driver testing method provided in an embodiment of this application; Figure 2 This is a flowchart of another kernel driver testing method provided in an embodiment of this application; Figure 3 This is a schematic diagram illustrating the specific implementation process of a kernel driver testing method provided in this application embodiment; Figure 4 This is a schematic diagram illustrating the specific implementation process of a kernel driver testing method based on the Syzkaller tool provided in this application embodiment; Figure 5 This is a structural block diagram of a kernel driver testing device provided in an embodiment of this application; Figure 6 This is a structural block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0013] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0014] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and are not limited in number; for example, a first object can be one or more. Furthermore, the term "and / or" in the specification and claims is used to describe the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. In the embodiments of this application, the term "multiple" refers to two or more, and other quantifiers are similar.

[0015] As modern operating systems become increasingly complex, the security and stability of kernel drivers have become paramount. Fuzzing, as an automated software testing technique, can detect potential defects and security vulnerabilities in kernel drivers by randomly mutating the input data.

[0016] In related technologies, when performing fuzz testing on kernel drivers, the test environment can be set up manually, including compiling a specified version of the kernel, compiling the driver to be tested, configuring a virtual machine environment, etc., and then running a fuzz testing tool to perform fuzz testing.

[0017] However, the methods for fuzzing the kernel driver of the operating system in related technologies require manually setting up a test environment for testing. Furthermore, when switching between different versions of the kernel driver during the testing process, the test environment needs to be rebuilt, which consumes a lot of resources and time, resulting in low testing efficiency.

[0018] For example, in the field of kernel driver testing, Syzkaller is a tool specifically designed for fuzzing the Linux operating system kernel, which can effectively discover security vulnerabilities in the kernel.

[0019] The kernel driver fuzzing process in related technologies typically includes the following steps: First, testers need to manually set up the test environment, including compiling a specific version of the kernel, compiling the driver to be tested, and configuring the virtual machine environment; second, run fuzzing tools (such as Syzkaller) to perform fuzzing; and finally, manually analyze, resolve, and verify the errors found during the testing process.

[0020] However, the kernel driver fuzzing method in related technologies has low test environment deployment efficiency. Each time the kernel or driver version is changed, the corresponding files need to be manually compiled, a very time-consuming and labor-intensive process. Furthermore, the kernel driver fuzzing method lacks sufficient concurrency capabilities, failing to perform parallel testing of multiple different kernel or driver versions, resulting in low testing efficiency. Additionally, when unexpected termination or crashes are detected, the kernel driver fuzzing method requires manual screening of crashes related to the device under test, manual analysis of crash reports, and writing code to reproduce the crashes. This entire process is not only time-consuming and labor-intensive but also has a high error rate.

[0021] Against this background, embodiments of this application provide a kernel driver testing method that can reduce the resources and time consumed in kernel driver testing and improve kernel driver testing efficiency.

[0022] The testing method for the kernel driver according to the embodiments of this application will be further described below with reference to the relevant accompanying drawings and examples: Figure 1 This is a flowchart illustrating the steps of a kernel driver testing method provided in an embodiment of this application. Figure 1 As shown, the method may include steps 101-103.

[0023] Step 101: Obtain the first image file, the second image file, and the testing requirements.

[0024] In this embodiment, the first image file is an image file of the test environment container obtained by containerizing the test environment, which can also be called a host container; the test environment is the running environment of the test tool when testing the kernel driver; the second image file is an image file of the container corresponding to the device under test (DUT), in which the kernel driver runs.

[0025] For example, an image file is a static, standardized, and portable snapshot file of a runtime environment in the container / virtualization field. It can be understood as an environment template containing complete runtime dependencies (such as file systems, toolchains, configurations, programs / kernels / virtual machines, etc.). It can be used to quickly create or start completely consistent container instances or virtualization environments and is the core carrier for environment reuse and consistent operation across platforms.

[0026] The first image file can be understood as an image (such as a Docker image) that has been containerized and packaged into the runtime environment of the testing tools. It can contain components necessary for running tests, such as testing tools, dependency libraries, and scripts. It can provide a standardized runtime environment for testing tools, ensuring that the testing process is consistent across different devices or scenarios, and avoiding unreliable results due to differences in testing tool versions.

[0027] The second image file can be understood as a containerized image corresponding to the device under test (DUT), simulating the DUT's operating environment. It may contain the kernel currently used by the DUT, the loaded graphics processing unit (GPU) driver, and dependencies supporting the kernel and driver operation (such as system libraries and configuration files). Alternatively, the second image file may only contain the currently used kernel and loaded drivers. Test requirements are used to indicate the test intent for the DUT.

[0028] Step 102: If the kernel driver in the second image file does not match the test requirements, generate a target kernel driver that matches the test requirements, and switch the kernel driver corresponding to the device under test to the target kernel driver.

[0029] In this embodiment, the test requirements may include a first version parameter of the kernel driver input by the user. The kernel driver version parameter in the second image file can be understood as the current kernel driver version parameter of the device under test. The first and second image files can be loaded, and the test environment container and the device under test container can be started according to the first version parameter input by the user. Communication between the two is then established via a network or shared directory to ensure that the test tool can access the device under test. The first version parameter input by the user and the kernel driver version parameter in the second image file are then compared to determine if they are consistent. If they are inconsistent, a target kernel driver corresponding to the first version parameter can be generated, and the current kernel driver of the device under test can be switched to the target kernel driver. For example, the current kernel driver of the device under test can be uninstalled, and the newly generated target kernel driver can be loaded, thereby completing the switching of the kernel driver corresponding to the device under test.

[0030] For example, if the current kernel version number of the device under test is 5.15.0-105-generic and the driver version number is 1.0, that is, the kernel driver version parameters in the second image file include the kernel version number as 5.15.0-105-generic and the driver version number as 1.0; the kernel version number that the user needs to test is 5.15.125 and the driver version number is 2.0, that is, the first version parameter input by the user includes the kernel version number as 5.15.125 and the driver version number as 2.0; the first version parameter is inconsistent with the kernel driver version parameter in the second image file, in this case, a kernel with version number 5.15.125 and a driver with version number 2.0 can be generated, that is, according to the first version parameter, a target kernel driver is generated, the kernel version number of the target kernel driver is 5.15.125, and the driver version number of the target kernel driver is 2.0. Then, the kernel version 5.15.0-105-generic and the driver version 1.0 in the device under test can be uninstalled, and the target kernel driver with kernel version 5.15.125 and driver version 2.0 can be loaded, so that the target kernel driver runs in the device under test, thereby completing the switching of the kernel driver corresponding to the device under test.

[0031] Step 103: Based on the first image file and the target kernel driver, test the device under test to obtain the test results of the device under test.

[0032] In this embodiment of the application, after switching the kernel driver corresponding to the device under test to the target kernel driver, the test environment container started based on the first image file can generate test cases and interact with the device under test to test the device under test and obtain the test results of the device under test.

[0033] For example, the test environment container sends operation instructions to the device under test (DUT) container through testing tools, such as calling driver interfaces, reading and writing files, etc. After receiving the instructions, the DUT container performs low-level hardware operations, such as GPU rendering, data calculation, etc., and returns the operation results to the test environment container. The test environment container can collect data in real time during the test process and synchronize this data to the host machine's local storage via network transmission or shared directory to obtain the test results of the DUT. The data collected in real time by the test environment container during the test process may include at least one of the following: the operation results of the DUT container (e.g., the status code returned by the driver, whether the function was successfully enabled, etc.), performance indicators (e.g., throughput, latency, resource utilization, etc.), and error logs (e.g., driver error information, kernel warnings, crash stacks, etc.). The network transmission method may include at least one of the following: transmission via Hypertext Transfer Protocol (HTTP), transmission via Secure Shell (SSH), etc.

[0034] This embodiment first obtains a first image file, a second image file, and test requirements. The first image file is defined as an image file of a test environment container obtained by containerizing the test environment; the test environment is the test runtime tool environment for testing the kernel driver; the second image file is an image file of a container corresponding to the device under test (DUT), in which the kernel driver runs; and the test requirements are used to indicate the test intent for the DUT. This makes the first and second image files equivalent to pre-built standardized test templates, eliminating the need to start from scratch for each test. Testing can be performed simply by starting the container based on the kernel driver version parameters input by the user, significantly shortening the preparation time before testing and thus improving testing efficiency. Secondly, if the kernel driver in the second image file does not match the test requirements, a target kernel driver matching the test requirements is generated, and the kernel driver corresponding to the DUT is switched to the target kernel driver. Finally, the DUT is tested based on the first image file and the target kernel driver to obtain the test results. The system can generate the target kernel driver that the user needs to test based on the test requirements, and switch the kernel driver directly within the container of the device under test. This eliminates the need to rebuild the entire test environment, reduces the resources consumed in the test process, and ensures that the switching process will not affect other environments. It only occupies the limited resources within the container, further improving test efficiency and enhancing the flexibility of kernel driver testing.

[0035] Figure 2 This is a flowchart illustrating the steps of another kernel driver testing method provided in this application embodiment. Figure 2As shown, the method may include steps 201-207.

[0036] Step 201: Obtain the first image file, the second image file, and the test requirements; the first image file is the image file of the test environment container obtained after containerizing the test environment; the test environment is the running environment of the test tool when testing the kernel driver; the second image file is the image file of the container corresponding to the device under test, the kernel driver runs in the device under test, and the test requirements are used to indicate the test intent for the device under test.

[0037] For details on the specific implementation of step 201, please refer to the relevant descriptions of the specific implementation of step 101 above, which will not be repeated here.

[0038] Step 202: If the kernel driver in the second image file matches the test requirements, test the device under test according to the first and second image files to obtain the test results of the device under test.

[0039] In this embodiment, the test requirements may include a first version parameter of the kernel driver input by the user. The kernel driver version parameter in the second image file can be understood as the current kernel driver version parameter of the device under test. The first and second image files can be loaded, and a test environment container and a device under test container can be started according to the first version parameter input by the user. Communication between the two is then established via a network or shared directory to ensure that the test tool can access the device under test. The first version parameter input by the user and the kernel driver version parameter in the second image file are then compared to determine if they are consistent. If they are consistent, the device under test can be directly tested using the test environment container started based on the first image file and the device under test container started based on the second image file, thus obtaining the test results for the device under test.

[0040] For example, if the current kernel version of the device under test (DUT) is 5.15.0-105-generic and the driver version is 1.0 (meaning the kernel driver version parameters in the second image file include kernel version 5.15.0-105-generic and driver version 1.0), and the kernel version to be tested by the user is also 5.15.0-105-generic and driver version 1.0 (meaning the first version parameter input by the user includes kernel version 5.15.0-105-generic and driver version 1.0), then it can be determined that the first version parameter is consistent with the kernel driver version parameter in the second image file. In this case, the test environment container can directly send test commands to the DUT container to verify the functionality, stability, or compatibility of the DUT's kernel driver. After receiving the test commands, the kernel driver in the DUT container executes the corresponding low-level operations and returns the operation results to the test environment container via the communication link. The test environment container can collect data in real time during the test process and synchronize this data to the local storage of the test environment container via network transmission or shared directory to obtain the test results of the device under test. The data collected in real time by the test environment container during the test can include the operational results of the device under test.

[0041] In this embodiment, by testing the device under test based on the first and second image files when the kernel driver version parameters in the first version are consistent with those in the second image file, the test results of the device under test can be obtained. This simplifies the testing process, further reduces the testing time, and improves the efficiency of kernel driver testing.

[0042] Step 203: If the kernel driver in the second image file does not match the test requirements, generate a target kernel driver that matches the test requirements, and switch the kernel driver corresponding to the device under test to the target kernel driver.

[0043] For details on the specific implementation of step 203, please refer to the relevant descriptions of the specific implementation of step 102 above, which will not be repeated here.

[0044] Optionally, the test requirements may include the first version parameters of the kernel driver input by the user; step 203 above may include sub-steps 2031-2033.

[0045] Sub-step 2031: If the version parameters of the first version are inconsistent with the version parameters of the kernel driver in the second image file, obtain the source code file of the kernel driver corresponding to the first version parameters.

[0046] Sub-step 2032: Convert the source code file of the kernel driver corresponding to the first version parameter into the test file of the target kernel driver.

[0047] In this embodiment, for sub-steps 2031-2032, the first version parameter is used to specify the kernel driver version that the user needs to test, and may include the kernel version number and driver version number input by the user. When the first version parameter is inconsistent with the kernel driver version parameter in the second image file, the source code file of the kernel driver corresponding to the first version parameter can be pulled from the code repository. Then, without relying on the container, the logic described in the high-level language of the kernel source code file is directly converted into a low-level binary file that can be recognized, executed, and verified by the environment in the physical machine or independent virtual machine, thereby obtaining the test file of the kernel driver corresponding to the first version parameter. Then, the source code file of the driver in the kernel driver corresponding to the first version parameter is pulled from the code repository, and the logic described in the high-level language of the driver's source code file is converted into a low-level binary file that can be recognized, executed, and verified by the environment in the container, thereby obtaining the test file of the driver in the kernel driver corresponding to the first version parameter. Based on the test file of the kernel in the kernel driver corresponding to the first version parameter and the test file of the driver, the test file of the kernel driver corresponding to the first version parameter is determined, that is, the test file of the target kernel driver.

[0048] Based on the above embodiments, exemplarily, the open-source hardware virtualization and emulator tool (Quick EMUlator, QEMU) can also be understood as a QEMU virtual machine. If the kernel driver version parameters in the second image file include a kernel version number of 5.15.0-105-generic and a driver version number of 1.0; and the first version parameters include a kernel version number of 5.15.125 and a driver version number of 2.0; and the first version parameters are inconsistent with the kernel driver version parameters in the second image file, then the source code file of the kernel with version number 5.15.125 can be pulled from the code repository, compiled, and a test file of the kernel with version number 5.15.125 can be obtained. Then, according to the container path mapping, the source code file of the driver with version number 2.0 can be pulled, compiled, and a test file of the driver with version number 2.0 can be obtained. Based on the test files for kernel version 5.15.125 and driver version 2.0, the test file for the kernel driver when kernel version 5.15.125 and driver version 2.0 is determined, which is the test file for the target kernel driver.

[0049] Sub-step 2033: Based on the test file of the target kernel driver, switch the kernel driver corresponding to the device under test to the target kernel driver.

[0050] In this embodiment, the currently running kernel driver in the device under test can be uninstalled, and a newly compiled target driver test file can be loaded to complete the kernel driver replacement. For example, if the kernel driver version parameters in the second image file include a kernel version number of 5.15.0-105-generic and a driver version number of 1.0, meaning the kernel driver currently running in the device under test has a kernel version number of 5.15.0-105-generic and a driver version number of 1.0, and the target kernel driver test file corresponds to a kernel version number of 5.15.125 and a driver version number of 2.0, the currently running kernel driver with a kernel version number of 5.15.0-105-generic and a driver version number of 1.0 in the device under test can be uninstalled, and the target kernel driver test file can be loaded, so that the kernel driver with a kernel version number of 5.15.125 and a driver version number of 2.0 runs in the device under test, thus completing the kernel driver replacement.

[0051] This embodiment obtains the source code file of the kernel driver corresponding to the first version parameter when the kernel driver version parameter in the first version parameter is inconsistent with that in the second image file. It then converts this source code file into a test file for the target kernel driver and switches the kernel driver corresponding to the device under test (DUT) to the target kernel driver based on the test file. This ensures that the driver ultimately running on the DUT is completely consistent with the user-specified first version parameter, meeting the user's testing requirements. Furthermore, it supports generating and switching specific versions of kernel drivers for different DUT devices or different test scenarios for the same device, satisfying complex needs such as multi-version compatibility testing and version iteration verification. Simultaneously, when testing different versions of kernel drivers, only the kernel driver of the DUT device needs to be switched, without redeploying the test environment, improving the flexibility and efficiency of kernel driver testing.

[0052] Optionally, step 203 above may also include sub-steps 2034-2036.

[0053] Sub-step 2034: If the kernel driver in the second image file does not match the test requirements, retrieve the test file of the target kernel driver that matches the test requirements from the historical test files.

[0054] In this embodiment of the application, when the kernel driver in the second image file does not match the test requirements, the system can search the historical test files to see if there is a test file for the target kernel driver that matches the test requirements.

[0055] For example, test requirements may include a first version parameter of the kernel driver input by the user. When the first version parameter is inconsistent with the kernel driver version parameter in the second image file, the system can query the historical test files to see if there is a test file for the kernel driver that matches the first version parameter.

[0056] Sub-step 2035: If the search is successful, then switch the kernel driver corresponding to the device under test to the target kernel driver according to the test file of the target kernel driver.

[0057] Based on the above embodiments, exemplarily, if a test file for a kernel driver matching the first version parameter is found in the historical test files, then the found test file for that kernel driver is used as the test file for the target kernel driver. Specifically, in each kernel driver test prior to this test, whenever the first version parameter is inconsistent with the kernel driver version parameter in the second image file, a test file for the target kernel driver is generated based on the first version parameter, and these target kernel driver test files are stored in a preset storage location. These target kernel driver test files stored in the preset storage location can be understood as the aforementioned historical test files.

[0058] For example, if the kernel version number in the first version parameter is 5.15.125 and the driver version number is 2.0, and the historical files include kernel driver test file 1 (kernel version number 5.15.125, driver version number 2.0), kernel driver test file 2 (kernel version number v5.4.2, driver version number 3.0), kernel driver test file 3 (kernel version number v5.4.3, driver version number 4.0), kernel driver test file 5 (kernel version number v5.4.4, driver version number 5.0), and kernel driver test file 6 (kernel version number v5.4.5, driver version number 6.0), when the first version parameter is inconsistent with the kernel driver version parameter in the second image file, kernel driver test file 1 (kernel version number 5.15.125, driver version number 2.0) can be found in the historical files, matching the kernel version number and driver version number in the first version parameter. Therefore, kernel driver test file 1 in the historical files can be used as the test file for the target kernel driver.

[0059] Sub-step 2036: If the search fails, obtain the source code file of the kernel driver corresponding to the first version parameter, convert the source code file of the kernel driver corresponding to the first version parameter into the test file of the target kernel driver, and switch the kernel driver corresponding to the device under test to the target kernel driver according to the test file of the target kernel driver.

[0060] In this embodiment, if no test file for the kernel driver matching the first version parameters is found in the historical test files, the matching fails. The source code file of the kernel driver corresponding to the first version parameters can be obtained from the code repository. The logic described in the high-level language of the source code file of the kernel driver corresponding to the first version parameters is converted into a low-level binary file that is recognizable, executable, and verifiable in this environment, thereby obtaining the test file for the target kernel driver. The kernel driver corresponding to the device under test is then switched to the target kernel driver based on the test file of the target kernel driver. Simultaneously, the test file of the target kernel driver obtained by compiling the source code file of the kernel driver corresponding to the first version parameters can also be stored in the aforementioned historical test files to provide data support for subsequent kernel driver testing.

[0061] The specific implementation of obtaining the target kernel driver's test file by compiling the kernel driver's source code file and switching the kernel driver corresponding to the device under test to the target kernel driver can be found in the relevant descriptions of sub-steps 2031-2033 above, and will not be repeated here.

[0062] This embodiment, when the kernel driver in the second image file does not match the test requirements, retrieves a test file of the target kernel driver that matches the test requirements from historical test files. If the retrieval is successful, the kernel driver corresponding to the device under test is switched to the target kernel driver based on the test file of the target kernel driver. If the retrieval fails, the source code file of the kernel driver corresponding to the first version parameter is obtained, converted into a test file of the target kernel driver, and the kernel driver corresponding to the device under test is switched to the target kernel driver based on the test file of the target kernel driver. When a test file of the target kernel driver matching the first version parameter exists in the historical test files, it can be directly reused without recompiling the target kernel driver test file, reducing the time spent compiling kernel driver test files, avoiding redundant use of central processing unit (CPU) and memory compilation resources, and further improving the testing efficiency of kernel drivers.

[0063] Optionally, step 203 above may also include sub-step 2037.

[0064] Sub-step 2037: If at least one set of version parameters in the first version parameters is inconsistent with the version parameters of the kernel driver in the second image file, generate the target kernel driver corresponding to the at least one set of version parameters according to the at least one set of version parameters, and switch the kernel driver of the device under test corresponding to the at least one set of version parameters to the target kernel driver corresponding to the at least one set of version parameters.

[0065] In this embodiment, the test requirements may include a first version parameter of the kernel driver input by the user. The first version parameter may include at least two sets of version parameters, each set of version parameters corresponding to a device under test (DUT). The first version parameter may include the kernel version number and driver version number input by the user, and may also include at least one of the following: the port number of the test environment container (i.e., the host port number), the number of DUTs, and the DUT port number, etc. Each set of version parameters may include at least one of the following: a kernel version number, a driver version number, a host port, and a DUT port input by the user. The number of DUTs in the first version parameter may be the same as the number of sets of version parameters.

[0066] For example, when the user-inputted first set of version parameters includes at least two sets of version parameters, if at least one set of version parameters is inconsistent with the kernel driver parameters of the kernel driver currently running on the DUT, that is, if at least one set of version parameters is inconsistent with the kernel driver version parameters in the second image file, the version parameter that is inconsistent with the kernel driver parameters of the kernel driver currently running on the DUT can be selected from the user-input at least two sets of version parameters. A target kernel driver can be generated based on the aforementioned inconsistent version parameter, and the kernel driver currently running on the DUT corresponding to the inconsistent version parameter can be switched, so that the kernel driver currently running on the DUT is switched to the target kernel driver.

[0067] Based on the above embodiments, for example, when the number of DUTs in the first version parameter input by the user is 3, 3 DUT containers can be started. The first version parameter input by the user includes 3 sets of version parameters: the first set of version parameters is DUT port number 20001, kernel version number 5.15.125, and driver version number 1.0; the second set of version parameters is DUT port number 20002, kernel version number v5.4.2, and driver version number 2.0; and the third set of version parameters is DUT port number 20003, kernel version number v5.4.3, and driver version number 3.0. The DUT port number can be used as the unique identifier of the DUT. If the kernel driver currently running on DUT with port number 20001 has a kernel version number of 5.15.125 and a driver version number of 1.0, while the other two DUTs currently running on DUTs both have kernel versions of 5.15.105 and driver versions of 5.0, then the first set of version parameters entered by the user is consistent with the kernel driver parameters of the kernel driver currently running on the DUT. The kernel driver currently running on DUT with port number 20001 will not be switched, and kernel driver testing can be performed directly. The second and third sets of version parameters input by the user are inconsistent with the kernel driver parameters of the kernel driver currently running on the DUT. Based on these user-inputted parameters, kernel driver 2 (kernel version v5.4.2, driver version 2.0) and kernel driver 3 (kernel version v5.4.3, driver version 3.0) can be generated. The kernel driver currently running on the DUT with port number 20002 will be switched to kernel driver 2, and the kernel driver currently running on the DUT with port number 20003 will be switched to kernel driver 3, thus enabling switching of kernel drivers for multiple DUTs. Subsequently, these three DUTs can be tested simultaneously, achieving the effect of testing multiple DUTs concurrently.

[0068] In some embodiments, when the number of DUTs in the first version parameter input by the user is 3, 3 DUT containers can be started. The first version parameter input by the user includes 3 sets of version parameters: the first set of version parameters is DUT port number 20001, kernel version number 5.15.125, and driver version number 1.0; the second set of version parameters is DUT port number 20002, kernel version number v5.4.2, and driver version number 2.0; and the third set of version parameters is DUT port number 20003, kernel version number v5.4.3, and driver version number 3.0. The DUT port number can be used as the unique identifier of the DUT. If the kernel version number of the kernel driver currently running in each DUT is 5.15.0 and the driver version number is 5.0, then each set of version parameters input by the user is inconsistent with the kernel driver version parameters of the kernel driver currently running in the DUT, that is, each set of version parameters input by the user is inconsistent with the kernel driver version parameters in the second image file. Based on each set of version parameters input by the user, kernel driver 1 (kernel version 5.15.125, driver version 1.0), kernel driver 2 (kernel version v5.4.2, driver version 2.0), and kernel driver 3 (kernel version v5.4.3, driver version 3.0) can be generated. The kernel driver currently running on the DUT with port number 20001 can be switched to kernel driver 1, the kernel driver currently running on the DUT with port number 20002 can be switched to kernel driver 2, and the kernel driver currently running on the DUT with port number 20003 can be switched to kernel driver 3, thus enabling switching of kernel drivers for multiple DUTs. Subsequently, these three DUTs can be tested simultaneously, achieving the effect of testing multiple DUTs concurrently.

[0069] This embodiment limits the test requirements to include a first version parameter of the kernel driver input by the user. This first version parameter can include at least two sets of version parameters, each corresponding to a device under test. If at least one set of version parameters in the first version parameter is inconsistent with the kernel driver version parameter in the second image file, a target kernel driver corresponding to the at least one set of version parameters is generated, and the kernel driver of the device under test corresponding to the at least one set of version parameters is switched to the target kernel driver. This allows each device under test to independently correspond to a different version of the kernel driver, thereby enabling parallel testing of multiple devices running different versions of the kernel driver. This improves the concurrency capability of kernel driver testing, further enhances kernel driver testing efficiency, increases the testing dimensions of kernel drivers, and reduces the risk of batch operations. For example, if all devices under test share the same version of the kernel driver, a hidden vulnerability in that version may cause all devices under test to fail or malfunction, affecting the entire testing process. However, when each device under test independently corresponds to a different version of the kernel driver, a problem with a single version only affects the corresponding device and will not spread to other devices.

[0070] Optionally, step 202 above may also include sub-steps 2021-2023.

[0071] Sub-step 2021: If the kernel driver in the second image file matches the test requirements, start the container of the test environment and the container of the device under test according to the test requirements, the first image file and the second image file.

[0072] Sub-step 2022: Control the container in the test environment to generate a key and send the key to the container of the device under test.

[0073] Sub-step 2023: In response to the container of the device under test receiving the key, the device under test is tested according to the first image file and the second image file to obtain the test results of the device under test.

[0074] In this embodiment, for sub-steps 2021-2023, if the kernel driver in the second image file matches the test requirements, the test environment container and the device under test container can be started simultaneously using a preset startup script, and the network can be configured to ensure communication between the two containers. Within the test environment container, an SSH key pair can be generated using a command-line tool (ssh-keygen) for generating SSH key pairs. This key pair can include a public key and a private key. The public key is sent to the device under test container via ssh-copy-id or Secure Copy (scp). The device under test container can receive this public key, and the test environment container can subsequently log in to the device under test container directly using the private key corresponding to this public key without entering a password. This enables passwordless connection between the test environment container and the device under test container, allowing testing of the device under test and obtaining the test results. ssh-copy-id is a convenient tool specifically designed for SSH public key authorization, which automatically copies the local public key to the configuration file of the remote device. This configuration file is a trust list recognized by the SSH protocol, recording all public keys allowed for passwordless login. scp is an SSH-based file transfer tool that allows secure file copying between local and remote devices. When sending a public key using scp, you need to manually add the public key to the configuration file of the device under test. This configuration file records all public keys authorized for passwordless login to the current device.

[0075] In one optional embodiment, the test script can be designed to be interactive. When a key needs to be sent, the user manually enters the password of the device under test according to the prompts, thereby testing the device under test based on the first image file and the second image file, and obtaining the test results of the device under test, so as to reduce the risk of password leakage.

[0076] This embodiment, by matching the kernel driver in the second image file with the test requirements, starts the test environment container and the device under test container according to the test requirements, the first image file, and the second image file. It then controls the test environment container to generate a key and send it to the device under test container. After receiving the key, the device under test container can perform tests based on the first and second image files to obtain the test results. This avoids storing the device under test password in plaintext in the script, reducing the risk of password leakage, improving test security, and ensuring smooth test execution. Furthermore, the SSH protocol encrypts transmitted data, preventing test commands or results from being eavesdropped on or tampered with. Simultaneously, the device under test container only allows access from the test environment holding the corresponding private key; other unauthorized devices cannot connect, ensuring the test process is undisturbed.

[0077] Step 204: Based on the first image file and the target kernel driver, test the device under test to obtain the test results of the device under test.

[0078] For details on the specific implementation of step 204, please refer to the relevant descriptions of the specific implementation of step 103 above, which will not be repeated here.

[0079] Step 205: Based on the identifier of the device under test, determine the location of the fault code corresponding to the identifier of the device under test in the fault index file.

[0080] Step 206: Extract the fault code sequence from the test log file based on the fault code location.

[0081] In this embodiment, for steps 205-206, a fault can represent a state where the program terminates unexpectedly due to an anomaly, also known as a crash. Test results can include at least one of the following: a test log file and a fault index file. The test log file can record the code sequence of all test cases; the fault index file can include at least one of the following: the correspondence between faults and devices, fault types, and fault code locations. After obtaining the test results, they can be stored in a designated folder. A preset script can periodically scan this folder. Based on the identifier of the device under test, the fault code location corresponding to the identifier of the device under test is determined in the fault index file of that folder. After determining the fault code location, the fault code sequence can be extracted from the test log file based on the fault code location.

[0082] For example, if the fault index file includes: fault_type: KASAN:slab-out-of-bounds fault_function: os_get_drm_device_by_fd function_offset: 0x157 function_total_length: 0x170 related_module: mtgpu cpu_id: 0 pid: 2909 comm: syz.1.378 tainted_flag: GD OE kernel_version: 5.15.125 #1 In this fault index file, the string following "Comm" is the fault code sequence number. The corresponding code sequence, i.e., the fault code sequence, can be extracted from this fault code sequence number.

[0083] Step 207: Generate the fault code file for the device under test based on the fault code sequence.

[0084] In this embodiment of the application, after the fault code sequence is extracted, it can be converted into a C code file that can be directly compiled and run, i.e., a fault code file. Engineers can use the C code file to reproduce the fault scenario locally and quickly locate program vulnerabilities.

[0085] This embodiment determines the location of the fault code corresponding to the identifier of the device under test (DUT) in the fault index file based on the fault code identifier. Then, it extracts the fault code sequence from the test log file based on the fault code location. Finally, it generates the fault code file for the DUT based on the fault code sequence. Automated scripts can be used to automatically locate and extract fault codes, improving fault handling efficiency and ensuring that the fault code location and operation sequence are completely consistent with the original log, thereby improving the success rate of fault reproduction.

[0086] Optionally, step 201 above may also include sub-steps 2011-2014.

[0087] Sub-step 2011: Convert the source code of the kernel in the kernel driver into a kernel file.

[0088] Sub-step 2012: Mount the kernel file in a preset virtual machine, and generate a third image file based on the preset virtual machine and the kernel file.

[0089] Sub-step 2013: In the container started based on the third image file, convert the source code of the driver in the kernel driver into a driver file.

[0090] Sub-step 2014: Install the driver file in the container that starts based on the third image file to obtain the container of the device under test corresponding to the kernel driver, and save the container of the device under test corresponding to the kernel driver as the second image file.

[0091] In this embodiment, for sub-steps 2011-2014, the high-level language description logic of the kernel source code in the kernel driver can first be converted into a low-level binary file that is recognizable, executable, and verifiable by the environment, thus obtaining the kernel file. This kernel file is then installed in a pre-deployed QEMU virtual machine to ensure that the kernel is loaded when the virtual machine starts. The current container environment is saved as a third image file. This current container environment contains the QEMU virtual machine and the kernel instance corresponding to the aforementioned kernel file; that is, the third image file can be understood as solidifying the currently running container environment (containing the QEMU virtual machine and the aforementioned kernel instance) into an image file. Then, the driver's source code is pulled. Within the container started based on the third image file, the driver's source code in the kernel driver is converted into a driver file, and the driver file is loaded into the kernel to verify that the driver can run normally. Finally, the current container environment is saved as a second image file. At this point, the current container environment contains the QEMU virtual machine, the kernel instance corresponding to the aforementioned kernel file, and the loaded driver. This second image file is the container image of the device under test.

[0092] Understandably, a container launched based on the third image file contains a QEMU virtual machine and a kernel instance corresponding to the aforementioned kernel file; a container launched based on the second image file contains a QEMU virtual machine, a kernel instance corresponding to the aforementioned kernel file, and the loaded driver.

[0093] For example, taking the Linux kernel as an example, a specified version of the Linux kernel can be compiled to generate a kernel file K, a QEMU virtual machine can be deployed and the kernel file K can be installed in it, the container environment at this time can be saved as image A, the driver to be tested can be compiled in the container based on image A, the driver file D can be generated and saved, the driver file D can be installed in the container based on image A, and finally the container environment at this time can be saved as image DUT.

[0094] The second image file generated in this embodiment is a reusable template for the device under test environment. When testing the same kernel driver version subsequently, the image file can be directly loaded without recompiling the kernel or deploying virtual machines. This provides data support for efficient execution in subsequent testing phases (such as rapid version switching and batch testing). Simultaneously, the image file records complete environment states, such as kernel version, driver version, compilation options, and virtual machine configuration. Regardless of the device on which the image is loaded, the startup environment remains completely consistent, reducing testing errors caused by differences in the testing environment.

[0095] In some embodiments, Figure 3 This is a schematic diagram illustrating the specific implementation process of a kernel driver testing method provided in an embodiment of this application. Figure 3As shown, during the system initialization phase, steps S1 and S2-S5 can be executed to build the container image files of the test environment (the first image file) and the container image file of the device under test (DUT) (the second image file). During the test execution phase, steps S6-S7 can be executed to start the container host (the container of the test environment) and the DUT (the container of the DUT). Then, it is determined whether the current kernel driver version running in the DUT matches the test requirements. If they match, step S9 is executed to start fuzz testing and redirect the process to the log file. That is, based on the first and second image files, the DUT is tested to obtain the test results, which are then recorded. If they do not match, step S8 is executed to automatically compile and switch the current kernel driver version running in the DUT to the version specified by the user input parameters. That is, based on the test requirements, a target kernel driver matching the test requirements is generated, and the kernel driver corresponding to the DUT is switched to the target kernel driver. Then step S9 is executed. After obtaining the test results, steps S10-S13 can be executed during the result analysis phase to automatically analyze the test results.

[0096] In some embodiments, Figure 4 This is a schematic diagram illustrating the specific implementation process of a kernel driver testing method based on the Syzkaller tool provided in this application embodiment. Figure 4 As shown, automating fuzz testing of GPU kernel drivers using the Syzkaller tool can include three stages: environment setup, fuzz testing, and result analysis. Based on the above embodiment, for example, a Syzkaller working directory, a one-click startup script, and container images can be pre-established. The container images include a host container image and a DUT container image. The Syzkaller working directory can manage all related files and store the kernel driver's source code.

[0097] During the environment setup phase, a pre-defined one-click startup script automatically mounts the working directory and starts the containers, essentially launching two containers and mounting the working directory within them. The Host container acts as the test control center, running the Syzkaller fuzzing system's control center, syz-manager, which manages the entire fuzzing process, including generating test cases, scheduling tasks, and monitoring target status. The DUT container serves as the test target, running the kernel driver (KMD) under test, responsible for executing test cases. If Syzkaller does not have a description file (Syscalls Description file), a description file can be written using Syzkaller's proprietary syzlang language. This description file defines the system calls and configuration commands provided by the kernel to be tested, as well as the data structures for the parameters and return values ​​of these commands. Syzkaller can then generate test cases based on this description file. The make tool can then be used to compile the written description file into a format that Syzkaller can directly use. If Syzkaller has a Syscalls Description file, the completeness of the functions in the file and the accuracy of the function definitions can be directly verified using the default verification tool. If the verification results meet the requirements, the folder can be mounted into the Host container to run syz-manager.

[0098] During the fuzzing phase, after the Host container and DUT container start, a fuzzing test parameter configuration file can be automatically generated. This configuration file can include at least one of the following: the function to be tested, the internet protocol (IP) address of the DUT container, and the port number of the DUT. The Host container can randomly generate test cases based on the description file and parameter configuration, and continuously send the generated test cases to the DUT container for execution, while monitoring the kernel status of the DUT. If the kernel crashes, freezes, or issues warnings, it means that a vulnerability may have been found. Finally, the fuzzing test results are generated, which may include the sequence of test cases that caused the kernel to crash and the corresponding kernel logs.

[0099] During the results analysis phase, the kernel log that caused the crash can be extracted from the test results, i.e., the crash log. Simultaneously, the problematic code sequence can be extracted, indicating which system call sequence triggered the crash. Based on the problematic code sequence, a reproducible C code file is generated, converting the internal system call sequence that caused the crash into a standard, independently compileable and runnable C program. Developers do not need to set up a complex fuzzing environment; they can directly compile and run this C program to reproduce the problem, greatly simplifying the debugging process. Finally, all information, including the crash log and reproducible code, can be compiled into a formatted vulnerability report form, i.e., a JIRA BUG, ​​containing all necessary information. Developers then debug and verify the bug using the JIRA BUG, ​​and finally fix the vulnerability (Debug), ultimately obtaining the fixed KMD. The fixed KMD can then be subjected to fuzz testing.

[0100] In summary, this embodiment of the application first obtains a first image file, a second image file, and test requirements. The first image file is defined as an image file of a containerized test environment, obtained by containerizing the test environment. The test environment is the runtime environment of the test tool when testing the kernel driver. The second image file is an image file of a container corresponding to the device under test (DUT), where the kernel driver runs. The test requirements indicate the test intent for the DUT. This makes the first and second image files equivalent to pre-built standardized test templates, eliminating the need to start from scratch for each test. Testing can be performed simply by starting the container according to the test requirements, significantly shortening the preparation time before testing and thus improving testing efficiency. Secondly, if the kernel driver in the second image file does not match the test requirements, a target kernel driver is generated according to the test requirements, and the kernel driver corresponding to the DUT is switched to the target kernel driver. Finally, the DUT is tested based on the first image file and the target kernel driver to obtain the test results. The system can generate the target kernel driver that the user needs to test based on the test requirements, and switch the kernel driver directly within the container of the device under test. This eliminates the need to rebuild the entire test environment, reduces the resources consumed in the test process, and ensures that the switching process will not affect other environments. It only occupies the limited resources within the container, further improving test efficiency and enhancing the flexibility of kernel driver testing.

[0101] This application also provides a kernel driver testing device. Figure 5 This is a structural block diagram of a kernel driver testing device provided in an embodiment of this application. Figure 5 As shown, the kernel-driven test device 500 may include: an acquisition module 501, a switching module 502, and a test module 503.

[0102] The acquisition module 501 is used to acquire a first image file, a second image file, and test requirements; the first image file is an image file of a container of the test environment obtained by containerizing the test environment; the test environment is the running environment of the test tool when testing the kernel driver; the second image file is an image file of a container corresponding to the device under test, and the kernel driver runs in the device under test; the test requirements are used to indicate the test intent for the device under test.

[0103] The switching module 502 is used to generate a target kernel driver that matches the test requirements when the kernel driver in the second image file does not match the test requirements, and to switch the kernel driver corresponding to the device under test to the target kernel driver.

[0104] Test module 503 is used to test the device under test based on the first image file and the target kernel driver, and obtain the test results of the device under test.

[0105] Optionally, the test requirements include the first version parameter of the kernel driver input by the user; the switching module 502 is specifically used to obtain the source code file of the kernel driver corresponding to the first version parameter when the first version parameter is inconsistent with the kernel driver version parameter in the second image file; convert the source code file of the kernel driver corresponding to the first version parameter into the test file of the target kernel driver; and switch the kernel driver corresponding to the device under test to the target kernel driver according to the test file of the target kernel driver.

[0106] Optionally, the switching module 502 is specifically used to retrieve a test file of the target kernel driver that matches the test requirements from historical test files when the kernel driver in the second image file does not match the test requirements; if the retrieval is successful, the kernel driver corresponding to the device under test is switched to the target kernel driver according to the test file of the target kernel driver; if the retrieval fails, the source code file of the kernel driver corresponding to the first version parameter is obtained, the source code file of the kernel driver corresponding to the first version parameter is converted into a test file of the target kernel driver, and the kernel driver corresponding to the device under test is switched to the target kernel driver according to the test file of the target kernel driver.

[0107] Optionally, the test requirements include a first version parameter of the kernel driver input by the user. The first version parameter includes at least two sets of version parameters, each set of version parameters corresponding to a device under test. The switching module 502 is specifically used to generate the target kernel driver corresponding to the at least one set of version parameters when there is an inconsistency between the first version parameter and the kernel driver version parameter in the second image file, and to switch the kernel driver of the device under test corresponding to the at least one set of version parameters to the target kernel driver corresponding to the at least one set of version parameters.

[0108] Optionally, the test module 503 is further configured to test the device under test based on the first image file and the second image file, if the kernel driver in the second image file matches the test requirements, and obtain the test results of the device under test.

[0109] Optionally, the test module 503 is specifically used to, when the kernel driver in the second image file matches the test requirements, start the container of the test environment and the container of the device under test according to the test requirements, the first image file and the second image file; control the container of the test environment to generate a key and send the key to the container of the device under test; in response to the container of the device under test receiving the key, perform tests on the device under test according to the first image file and the second image file to obtain the test results of the device under test.

[0110] Optionally, the test results include at least one of the following: test log file, fault index file; such as Figure 5 As shown, the kernel-driven test device 500 may include a processing module 504.

[0111] The processing module 504 is used to determine the location of the fault code corresponding to the identifier of the device under test in the fault index file according to the identifier of the device under test; extract the fault code sequence from the test log file according to the fault code location; and generate a fault report of the device under test according to the fault code sequence.

[0112] Optionally, the acquisition module 501 is specifically used to convert the source code of the kernel in the kernel driver into a kernel file; mount the kernel file in a preset virtual machine, and generate a third image file based on the preset virtual machine and the kernel file; in a container started based on the third image file, convert the source code of the driver in the kernel driver into a driver file; install the driver file in the container started based on the third image file to obtain a container of the device under test corresponding to the kernel driver, and save the container of the device under test corresponding to the kernel driver as a second image file.

[0113] This application also provides an electronic device, with reference to... Figure 6 , Figure 6 This is a structural block diagram of an electronic device for kernel driver testing provided in an embodiment of this application. Figure 6 As shown, the electronic device includes: a processor, a memory, a communication interface, and a communication bus. The processor, the memory, and the communication interface communicate with each other through the communication bus. The memory is used to store executable instructions, which cause the processor to execute the kernel-driven test method of the aforementioned embodiment.

[0114] The processor can be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable devices, transistor logic devices, hardware components, or any combination thereof. The processor can also be a combination that implements computational functions, such as a combination of one or more microprocessors, or a combination of a DSP and a microprocessor.

[0115] The communication bus may include a path for transmitting information between the memory and the communication interface. The communication bus may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. The communication bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 6 The symbol is represented by only one line, but this does not mean that there is only one bus or one type of bus.

[0116] This application also provides a non-transitory computer-readable storage medium, which, when the instructions in the storage medium are executed by the processor of an electronic device (server or terminal), enables the processor to perform... Figure 1 or Figure 2 The kernel driver testing method is shown.

[0117] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0118] Those skilled in the art will understand that embodiments of this application can be provided as methods, apparatus, or computer program products. Therefore, embodiments of this application can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of this application can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0119] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, as well as 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 terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0120] These computer program instructions may also be stored in a computer-readable storage medium capable of directing a computer or other programmable data processing terminal device to operate in a predictive 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 function specified in one or more boxes.

[0121] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment 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.

[0122] Although preferred embodiments of the present application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present application.

[0123] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0124] The above provides a detailed description of the kernel driver testing method, apparatus, electronic device, and computer-readable storage medium provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A kernel driver testing method, characterized in that, The method includes: Obtain a first image file, a second image file, and test requirements; the first image file is an image file of a container of the test environment obtained by containerizing and encapsulating the test environment; the test environment is the runtime environment of the test tool when testing the kernel driver; the second image file is an image file of a container corresponding to the device under test, and the kernel driver runs in the device under test; the test requirements are used to indicate the test intent for the device under test; If the kernel driver in the second image file does not match the test requirements, a target kernel driver that matches the test requirements is generated according to the test requirements, and the kernel driver corresponding to the device under test is switched to the target kernel driver. The device under test is tested based on the first image file and the target kernel driver to obtain the test results of the device under test.

2. The method according to claim 1, characterized in that, The test requirements include the first version parameters of the kernel driver input by the user; In the case where the kernel driver in the second image file does not match the test requirements, a target kernel driver matching the test requirements is generated according to the test requirements, and the kernel driver corresponding to the device under test is switched to the target kernel driver, including: If the first version parameter is inconsistent with the kernel driver version parameter in the second image file, obtain the source code file of the kernel driver corresponding to the first version parameter; Convert the source code file of the kernel driver corresponding to the first version parameter into the test file of the target kernel driver; Based on the test file of the target kernel driver, the kernel driver corresponding to the device under test is switched to the target kernel driver.

3. The method according to claim 1, characterized in that, In the case where the kernel driver in the second image file does not match the test requirements, a target kernel driver matching the test requirements is generated according to the test requirements, and the kernel driver corresponding to the device under test is switched to the target kernel driver, including: If the kernel driver in the second image file does not match the test requirements, retrieve the test file of the target kernel driver that matches the test requirements from the historical test files; If the search is successful, the kernel driver corresponding to the device under test will be switched to the target kernel driver according to the test file of the target kernel driver; If the search fails, the source code file of the kernel driver corresponding to the first version parameter is obtained, the source code file of the kernel driver corresponding to the first version parameter is converted into a test file of the target kernel driver, and the kernel driver corresponding to the device under test is switched to the target kernel driver according to the test file of the target kernel driver.

4. The method according to claim 1, characterized in that, The test requirements include the first version parameters of the kernel driver input by the user. The first version parameters include at least two sets of version parameters, and each set of version parameters corresponds to one of the devices under test. In the case where the kernel driver in the second image file does not match the test requirements, a target kernel driver matching the test requirements is generated according to the test requirements, and the kernel driver corresponding to the device under test is switched to the target kernel driver, including: If at least one set of version parameters in the first version parameters is inconsistent with the version parameters of the kernel driver in the second image file, the target kernel driver corresponding to the at least one set of version parameters is generated according to the at least one set of version parameters, and the kernel driver of the device under test corresponding to the at least one set of version parameters is switched to the target kernel driver corresponding to the at least one set of version parameters.

5. The method according to claim 1, characterized in that, The method further includes: If the kernel driver in the second image file matches the test requirements, the device under test is tested according to the first image file and the second image file to obtain the test results of the device under test.

6. The method according to claim 5, characterized in that, If the kernel driver in the second image file matches the test requirements, the device under test is tested based on the first image file and the second image file to obtain the test results of the device under test, including: If the kernel driver in the second image file matches the test requirements, then according to the test requirements, the first image file, and the second image file, start the container of the test environment and the container of the device under test. The container in the test environment is controlled to generate a key, and the key is sent to the container of the device under test. In response to the container of the device under test receiving the key, the device under test is tested according to the first image file and the second image file to obtain the test result of the device under test.

7. The method according to claim 1, characterized in that, The test results include at least one of the following: test log file, fault index file; The method further includes: Based on the identifier of the device under test, determine the location of the fault code corresponding to the identifier of the device under test in the fault index file; Extract the fault code sequence from the test log file based on the fault code location; Based on the fault code sequence, a fault code file for the device under test is generated.

8. The method according to claim 1, characterized in that, The process of obtaining the second image file includes: Convert the kernel source code in the kernel driver into a kernel file; The kernel file is mounted in a preset virtual machine, and a third image file is generated based on the preset virtual machine and the kernel file; In the container started based on the third image file, the source code of the driver in the kernel driver is converted into a driver file; The driver file is installed in a container that is started based on the third image file to obtain a container for the device under test corresponding to the kernel driver, and the container for the device under test corresponding to the kernel driver is saved as the second image file.

9. A kernel-driven testing device, characterized in that, The device includes: The acquisition module is used to acquire a first image file, a second image file, and test requirements; the first image file is an image file of a container of the test environment obtained by containerizing and encapsulating the test environment; the test environment is the runtime environment of the test tool when testing the kernel driver; the second image file is an image file of a container corresponding to the device under test, and the kernel driver runs in the device under test; the test requirements are used to indicate the test intent for the device under test; The switching module is used to generate a target kernel driver that matches the test requirements when the kernel driver in the second image file does not match the test requirements, and to switch the kernel driver corresponding to the device under test to the target kernel driver. The testing module is used to test the device under test based on the first image file and the target kernel driver, and obtain the test results of the device under test.

10. An electronic device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the method as described in any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, When the instructions in the computer-readable storage medium are executed by the processor of the electronic device, the electronic device is enabled to perform the method as described in any one of claims 1 to 8.

Images