Kernel boot test method for enhancing startability and stability by using Ranconfig for edge device

Abstract

The invention discloses a kernel boot test method for enhancing startability and stability by using Ranconfig for an edge device, which comprises the following steps of: generating a random kernel configuration file by using a Ranconfig tool, carrying out compiling and startup test on the generated configuration file, repairing a non-startable configuration file by using a config-bias algorithm, and carrying out kernel boot test on the kernel configuration file by using the Ranconfig tool. Generating a configuration item difference set according to the difference between the minimum default configuration file and the to-be-repaired configuration file, iteratively positioning configuration items failed to start and recording the configuration items to a key configuration database; the repaired kernel is further subjected to a pressure test through a fuzzy test module, and a black list and a white list are generated in combination with equipment hardware resources, so that configuration items are optimized, and the test coverage rate is increased; according to the invention, the availability and the stability of the kernel boot test of the edge device are improved.

Description

Technical Field

[0001] The present invention relates to the technical field of Linux operating system, and in particular to a kernel boot test method for edge devices using Randconfig to enhance the bootability and stability. Background Art

[0002] Kernel configuration and kernel testing are key steps to ensure the bootability and stability of the Linux kernel. Taking the Linux system as an example, the Linux kernel currently contains more than 15,000 configuration options, and the number is increasing with each version update. Each configuration item represents a specific functional module in the kernel. Its diversity and complexity make the kernel configuration problem theoretically analogous to the subset and subgroup problem in a high-dimensional configuration space. The search space for this problem is growing exponentially, and it is difficult to cover all possible configuration combinations by manually writing test cases, resulting in potential problems that can often only be discovered in actual applications. Especially in the field of edge devices, the challenges faced by kernel configuration and testing are more prominent, which usually run in resource-constrained environments, such as low-power CPUs and limited memory, and require highly customized kernel configurations to strike a balance between functionality and resource usage. In addition, the hardware platforms and application scenarios of edge devices are diverse, such as IoT devices, smart sensors, and drones. The startup process of these devices places higher requirements on the reliability and stability of kernel configuration, and existing testing tools are difficult to balance the generality and specific scenario requirements.

[0003] Traditional kernel configuration methods (such as make config and make menuconfig) ensure the bootability of the kernel by manually selecting and adjusting configuration items, but they are inefficient and cannot adapt to the increasingly complex configuration options. Research in recent years has focused on automated testing and optimizing test tools to improve coverage, but existing fuzz testing tools (such as Syzkaller) still have deficiencies in test efficiency and coverage when faced with large-scale combinations of configuration options. Randconfig, as a method for randomly generating kernel configurations, can effectively increase the diversity and coverage of configuration options. However, the configuration files generated by Randconfig are usually not directly used for bootable kernel startup testing, and existing research on the application of Randconfig in kernel startup testing is also rare.

[0004] At the same time, the unique needs of edge devices further highlight the importance of improving kernel testing and kernel boot repair. The bootability and stability of the kernel are crucial to practical applications, but its resource-constrained nature limits the applicability of large-scale testing tools. Summary of the invention

[0005] To solve the above problems in the prior art, the present invention proposes a kernel boot test method for edge devices using Randconfig to enhance bootability and stability, automatically generating and testing a large number of random kernel configurations to identify and repair configuration items that cause kernel boot failures, and ultimately improving the stability and performance of the operating system kernel in edge devices. This is in response to the characteristics of edge devices with limited resources, diverse hardware platforms, and complex application scenarios.

[0006] The present invention provides a kernel boot test method for edge devices using Randconfig to enhance bootability and stability, comprising the following steps: (1) Call the Randconfig toolchain through the configuration generation module to generate a specified number of kernel configuration files based on random seeds; (2) Compile and start the configuration file generated in step (1) through the kernel repair module, and use the config-bisect algorithm to repair the unbootable configuration file; (3) Perform fuzz testing on the repaired kernel through the data analysis module, dynamically generate blacklists and whitelists based on device hardware resources to optimize configuration, and record key configuration item data to improve test coverage Furthermore, in step (1), the random seed is generated by calculating the number of microseconds of the system time; the configuration generation process includes randomly enabling / disabling Boolean configuration items, randomly taking values ​​for numeric configuration items, and randomly selecting predefined values ​​for string configuration items; the number of configuration files generated is 1 million to 2 million.

[0007] Furthermore, the config-bisect algorithm in step (2) includes: (21) Generate a configuration item difference set based on the difference between the minimum default configuration file and the configuration file to be repaired; (22) Divide the difference set into subsets for iterative testing, and use the binary method to locate the configuration item that causes the startup failure; (23) Record the successfully repaired configuration items into the key configuration database.

[0008] Furthermore, a minimum default configuration file is generated by the `make olddefconfig` command, and the startup test is executed in the QEMU virtualization platform.

[0009] Furthermore, the generation of the blacklist and whitelist in step (3) includes: obtaining device hardware information through the system interface; adding resource-consuming configuration items to the blacklist; adding the lightweight scheduler and the low-power management module to the whitelist; and dynamically updating the list rules based on the fuzzy test results; wherein the hardware information includes: CPU architecture, memory capacity, network bandwidth; and the consuming configuration items include: graphics driver, complex file system.

[0010] Furthermore, it also includes: integrating the commit-binary location tool to locate the code commit that caused the kernel startup failure through the Git binary strategy; associating the repaired configuration items with the historical commits to generate a traceable configuration item change record.

[0011] Furthermore, the data analysis module further includes: parsing the Kconfig file, and storing the configuration items by menuconfig / choice / menu hierarchy classification; outputting the classification results in JSON format for subsequent configuration item impact analysis.

[0012] Furthermore, fuzz testing adopts an enhanced testing framework that covers the following testing dimensions: compatibility testing of kernel configuration item combinations; abnormal input testing of system call interfaces; and boundary value testing of kernel startup parameters.

[0013] An electronic device described in the present invention includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the computer program is loaded into the processor, it implements any one of the kernel boot test methods for edge devices using Randconfig to enhance bootability and stability.

[0014] A storage medium described in the present invention stores a computer program, and when the computer program is executed by a processor, it implements any one of the kernel boot test methods for edge devices using Randconfig to enhance the bootability and stability.

[0015] Beneficial effects: Compared with the prior art, the present invention has the following advantages: the present invention can quickly generate highly customized kernel configurations to adapt to the current use environment of specific devices and meet their strict requirements for kernel startup time and stability, generate a large number of random kernel configuration files through Randconfig, perform kernel compilation and QEMU test startup, automatically repair unbootable kernel configuration files, and perform fuzz testing on bootable kernel images. During the test process, the key configuration items that affect kernel startup are continuously recorded, and the data is analyzed to optimize the kernel configuration and test process. Experimental results show that compared with traditional fuzz testing tools, this method performs better in test coverage, vulnerability detection capabilities and repair efficiency, and is particularly suitable for kernel optimization of edge devices and large-scale kernel development and testing scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 is a flow chart of the present invention; Figure 2 A schematic diagram of the root file system creation process of the present invention; Figure 3An example of booting a kernel for a virtualization platform of the present invention; Figure 4 The present invention repairs the execution flow of the config-bisect algorithm. DETAILED DESCRIPTION

[0017] The present invention will be further explained and illustrated below in conjunction with the accompanying drawings and specific embodiments. It should be understood that the embodiments are only used to illustrate and explain the present invention, and do not impose any limitation on the scope of implementation of the present invention.

[0018] The present invention provides a kernel boot test method for edge devices using Randconfig to enhance bootability and stability, comprising the following steps: S1 Figure 1 The configuration item generation module in the target version of Linux source code is input as the basis, and then the make randconfig command is run to randomly generate 1.5 million random kernel configuration items. For the Randconfig command, it takes the microseconds of the current system time by executing the algorithm located in / scripts / kconfig / confdata.c and / scripts / kconfig / conf.c, calculates the initial seed of the random function based on the microseconds, and ensures that the random number sequence obtained each time is different to generate different kernel configurations; for each Boolean option, a random number between 0 and 1 is generated to determine whether it is enabled or disabled; for each numeric option, a random number within the allowed range is generated; and for the string option, a value is randomly selected from the predefined string list. The specific algorithm is as follows: The S2 kernel repair module compiles the kernel according to the generated configuration file and performs boot tests to repair the unbootable kernel. This module is written in shell to ensure automated management and mainly includes two processes: (a) kernel compilation and boot test and (b) kernel repair.

[0019] For process (a), if Figure 2 As shown, the present invention takes arm64 (aarch64) as an example in the compilation and startup test process. By setting the compilation environment, using the GCC compiler to compile the kernel, and using the automated script to manage the compilation process, an efficient and reliable kernel compilation process is achieved. The automated script will return the running log directory of this kernel configuration file startup test at the end of the test task. By reading and analyzing the log, the startup result of the configuration file generated by Randconfig can be known. The present invention uses the QEMU virtualization platform to perform kernel boot testing, Figure 3 shows an example of kernel boot testing using QEMU.

[0020] Randconfig provides extensive test coverage, but also creates a high degree of uncertainty. In the exponentially growing space of configuration options, most combinations are not verified or optimized, and there may be conflicts or missing dependencies. Therefore, in most cases, after the kernel is compiled and mounted to the root file system, the generated .config file will not be able to boot successfully. To make these kernels bootable, the key is to fix and adjust the configuration items in the .config file.

[0021] For process (b), the kernel is repaired to be a bootable kernel based on the configuration item changes in the kernel configuration file .config. Figure 4 A complete repair process is shown, such as Figure 4 , the specific steps are as follows: a1 prepares Good-config. The source of Good-config can be any bootable configuration file. Considering the differences in bootable configuration files of various platforms and the need to quickly obtain a bootable configuration file to meet the needs of automated testing, the present invention uses the make olddefconfig command provided by the Linux kernel to generate a minimum default configuration file based on the current system platform, which can be started.

[0022] a2 obtains the configuration item difference set config-temp. Compare the differences between Good-config and Bad-config, obtain the Good-config, but the configuration items that are not in Bad-config, and the configuration items in Bad-config that are modified by Good-config. Record these configuration items in the config-temp set.

[0023] a3 divides the config-temp difference set into two halves, one half is A and the other half is B.

[0024] a4 tests the startup result of A+ Bad-config and starts the loop. It includes the following steps:

[0025] If a41 is successfully started, it means that too many have been added. Then, it will be divided into two halves A / 2 based on A, and the startup result of A / 2+Bad-config will be tested until it cannot be started. The configuration file bootable-config and configuration item bootable-items before the failure to start will be recorded, and the cycle ends.

[0026] a42 If A+Bad-config fails to start, then add B and test the startup result of A+B+Bad-config. If it can start, then divide it into two halves based on B and test the startup result of A+B / 2+Bad-config until it cannot start. Similarly, record bootable-config and configuration items bootable-items, and the loop ends.

[0027] a5 writes bootable-config to the file to obtain the repaired bootable configuration file.

[0028] a6 records the list of configuration items added and deleted in this repair.

[0029] In the Kconfig classification part of the S3 data analysis module, the present invention designs a general Kconfig syntax classification algorithm, analyzes the Kconfig configuration file obtained in the previous section, and classifies the common configuration item files that can be started and cannot be started. The specific steps are as follows: S31 Initialize the configuration item classification result config_typed_dict is empty; S32 reads the first line of the Kconfig file content according to kconfig_filepath; If the file end mark is not read in S33, the parsing is started; S331 If this line matches the syntax menuconfig, choice, menu keywords, then parse the new category name c_new according to the syntax rules, if the current category c_current exists, make the new category c_new a subcategory of the current category c_current, set the current category to the new category c_current=c_new, and store the category in config_typed_dict; S332 If this line matches the syntax config, the configuration item name config_item is obtained by parsing according to the syntax rule, and config_item is stored in the category c_current and recorded in config_typed_dict; S333: If this line matches the syntax source keyword, then parse and match the syntax rule to obtain a new Kconfig path new_kconfig_filepath, set kconfig_filepath=new_kconfig_filepath, and go to step S331; S334 reads the next line of the Kconfig file and goes to step S333 to continue the loop; S34 saves the classification result config_typed_dict and outputs it to a physical file in JSON format.

[0030] The blacklist and whitelist part of the S4 data analysis module is designed to automatically optimize the kernel configuration according to the specific resource requirements of the device (such as low-power ARM architecture CPU, limited memory and network bandwidth) to improve the performance and resource utilization efficiency of edge devices. The specific implementation method is as follows: First, the module analyzes the current resource status of the device based on the hardware information of the edge device (such as CPU architecture, memory size, network connection speed, etc.). This process automatically identifies the device configuration by calling the system hardware information interface (lscpu, free, and ifconfig).

[0031] Then, based on the data before and after each kernel repair, the module further analyzes the impact of the current kernel configuration on device resources, and automatically adds unnecessary configuration items such as graphics processing modules, virtualization support, and large file systems to the block list. For example, high-performance graphics drivers, large or complex file systems (ext4, xfs), and uncommon hardware modules are disabled to save memory and processing power. According to the needs of edge devices, lightweight schedulers (CFS schedulers), low-power management modules, simplified network protocol stacks, etc. are added to the allowed list to improve the device's response speed and resource utilization. After each kernel repair, the module will automatically modify the kernel configuration file based on the current device's resource status and optimization strategy. The generated configuration file will be automatically tested by scripts to ensure that the repaired kernel can be efficiently started and run on the edge device. After the kernel configuration is adjusted, the module will run the kernel test again and record performance data to feedback the optimization results. Based on the feedback data, the module will dynamically update the black and white list rules and further adjust the configuration to ensure the best resource adaptation effect.

[0032] This module enables automatic kernel optimization based on edge device resources, minimizes the kernel's waste of hardware resources, and improves the operating efficiency of edge devices under low power consumption and limited resource conditions.

[0033] The benchmark Linux kernel version selected by the present invention is 5.10, which is particularly suitable for the development needs of edge devices due to its long-term support and stability. The system environment for testing and optimization operation is based on OpenEuler 20.03-LTS-SP1. As a rising star of domestic operating systems, this system is known for its good support for resource-constrained devices and high-performance characteristics. The compiled kernel is boot tested using QEMU 7.0.0. The automation and flexibility of the test process are achieved through Shell scripts, which occupy most of the program code. In addition, in order to improve data processing capabilities and operating efficiency, part of the server-side logic is written in Crystal and Ruby to meet the needs of data transmission and state synchronization in edge device scenarios.

[0034] Table 1 Kernel boot results before and after repair ; Randconfig of the present invention is used to randomly generate a configuration file to create 1.5 million kernels for repair. The startup results before and after the repair are shown in Table 1, using the 5.10 version kernel with the randomly generated configuration file as the input of the kernel repair. The success rate of booting the kernel directly from the configuration file generated by Randconfig is about 5% to 10%. After the system repair developed based on the enhanced kernel startup test method, the success rate of starting the same batch of kernels reached 91.263%, and the repair effect was remarkable.

[0035] Table 2 Comparison of error repair time ; Kernel startup exceptions often occur because after the kernel source code version is upgraded, the old kernel configuration file is incompatible with the new kernel version. This incompatibility may be caused by the introduction of new features or the removal of features that affect the kernel startup process. In order to quickly locate the key commit that causes this problem, the present invention combines the improved kernel startup test method with the git bisection strategy to create a commit-split abnormal commit location tool, such as Figure 1As shown in the implementation section. In order to verify the effectiveness of the abnormal commit localization tool (commit-bisect) in actual kernel development, an experiment was conducted to simulate the collaborative development process of the Linux kernel, with the aim of testing the tool's ability to locate kernel boot failures caused by configuration file errors or code changes. First, the main branch of torvalds / linux was pulled out. The latest commit of this branch was used as the initial baseline for the experiment to ensure that it can be successfully compiled and started in the environment described above. Second, in order to simulate the actual collaborative development scenario, a series of commits were designed to intentionally introduce bugs that would cause the kernel to fail to boot. Two different types of commits were made during the experiment: Kernel commits that can be booted (good commits): A set of tested kernel versions that can be booted normally is provided as a baseline for good commits. Commits caused by incorrect configuration (bad Commit): Subsequent commits intentionally introduced incorrect configuration files, causing the kernel to fail to boot. This type of error includes missing configuration of critical modules and introducing incompatible options, thus forming incorrect commits. These commits form a commit sequence containing multiple incorrect commits, simulating kernel boot failures that may occur during the development process. After building the bad commit sequence, the commit-bisect tool is used to automatically locate kernel boot failures. The experiment simulated multiple commit sequences, and the tool successfully located each commit that introduced errors, verifying its effectiveness in kernel boot failures. During the experiment, the tool significantly reduced the time cost of problem location. The specific results of the experiment are shown in Table 2. The experiment demonstrated the significant advantages of the commit-split tool in finding faulty commits. Compared with the traditional linear search method of manual debugging, the tool uses binary search, which greatly reduces the number of test commits and reduces the time complexity from O(n) to O(log n). In addition, the tool's automated process reduces the need for manual intervention, quickly locates problematic commits, and improves the debugging efficiency of the kernel development process.

[0036] Table 3 Comparison of features of popular testing tools ; As shown in Table 3, the characteristics of common fuzz testing tools related to Linux kernel testing are shown, but the characteristics of automated testing and repairing kernel configuration items are unique to the enhanced fuzz testing tool designed by the present invention.

[0037] Table 4 Comparison between the fuzz testing tool of the present invention and Syzkaller ; The performance of the fuzz testing tool designed by the present invention is compared with that of the traditional fuzz testing tool (Syzkaller). The performance is evaluated from four aspects: vulnerability detection capability, configuration coverage, repair capability, and resource consumption. The experimental results are shown in Table 4. Under the same test environment and time constraints, the fuzz testing tool designed by the present invention found a total of 220 potential vulnerabilities, which is 46.7% more than the 150 vulnerabilities found by Syzkaller. Using LCONV to obtain the test coverage, the test coverage of this paper reached 95%, which is higher than Syzkaller's 70%. These two advantages are mainly due to the different kernel configurations generated by randconfig. In addition, the system of the present invention can automatically repair the kernel that cannot be started in 91% of the time, which further ensures that the fuzz test can run smoothly under multiple kernel configurations. In terms of resource consumption, the system of the present invention runs for 26.5 hours in 24 hours, and the CPU utilization is 82%. The running time of Syzkaller is 25 hours, and the CPU utilization is 80%. Compared with Syzkaller, the enhanced fuzz testing tool designed by the present invention can find more potential vulnerabilities without increasing resource usage. This experiment proves that the fuzz testing tool combined with the enhanced kernel boot testing method has significant advantages in test coverage, vulnerability detection capability, and repair efficiency.

Claims

1. A kernel boot test method for edge devices using Randconfig to enhance bootability and stability, characterized in that: The following steps are involved: (1) Call the Randconfig toolchain through the configuration generation module to generate a specified number of kernel configuration files based on random seeds; (2) Compile and start the configuration file generated in step (1) through the kernel repair module, and use the config-bisect algorithm to repair the unbootable configuration file; (3) Perform fuzz testing on the repaired kernel through the data analysis module, dynamically generate blacklists and whitelists based on device hardware resources to optimize the configuration, and record key configuration item data to improve test coverage.

2. A kernel boot test method for edge devices using Randconfig to enhance bootability and stability according to claim 1, characterized in that: In step (1), the random seed is generated by calculating the number of microseconds of the system time; the configuration generation process includes randomly enabling / disabling Boolean configuration items, randomly taking values ​​for numeric configuration items, and randomly selecting predefined values ​​for string configuration items; the number of configuration files generated is 1 million to 2 million.

3. A kernel boot test method for edge devices using Randconfig to enhance bootability and stability according to claim 1, characterized in that: The config-bisect algorithm in step (2) includes: (21) Generate a configuration item difference set by comparing the difference between the minimum default configuration file and the configuration file to be repaired; (22) Divide the difference set into subsets for iterative testing, and use the binary method to locate the configuration item that causes the startup failure; (23) Record the successfully repaired configuration items into the key configuration database.

4. A kernel boot test method for edge devices using Randconfig to enhance bootability and stability according to claim 3, characterized in that: A minimal default configuration file is generated by the `make olddefconfig` command, and the startup test is performed in the QEMU virtualization platform.

5. A kernel boot test method for edge devices using Randconfig to enhance bootability and stability according to claim 1, characterized in that: The generation of the blacklist and whitelist in step (3) includes: obtaining device hardware information through the system interface; adding resource-consuming configuration items to the blacklist; adding the lightweight scheduler and low-power management module to the whitelist; and dynamically updating the list rules based on the fuzzy test results; wherein, the hardware information includes: CPU architecture, memory capacity, network bandwidth; and the consuming configuration items include: graphics driver, complex file system.

6. A kernel boot test method for edge devices using Randconfig to enhance bootability and stability according to claim 1, characterized in that: Also includes: Integrated commit-binary location tool, which uses Git binary strategy to locate the code commit that causes kernel startup failure; Associate the repaired configuration item with the historical submission to generate a traceable configuration item change record.

7. A kernel boot test method for edge devices using Randconfig to enhance bootability and stability according to claim 1, characterized in that: The data analysis module further includes: parsing the Kconfig file, storing the configuration items by menuconfig / choice / menu level classification; outputting the classification results in JSON format for subsequent configuration item impact analysis.

8. A kernel boot test method for edge devices using Randconfig to enhance bootability and stability according to claim 1, characterized in that: Fuzz testing uses an enhanced testing framework that covers the following testing dimensions: compatibility testing of kernel configuration item combinations; abnormal input testing of system call interfaces; and boundary value testing of kernel startup parameters.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the computer program is loaded into the processor, a kernel boot test method for edge devices using Randconfig to enhance bootability and stability is implemented according to any one of claims 1 to 8.

10. A storage medium storing a computer program, characterized in that: When the computer program is executed by the processor, a kernel boot test method for edge devices using Randconfig to enhance bootability and stability is implemented according to any one of claims 1 to 8.

Images