A Kernel Boot Testing Method for Enhancing Bootability and Stability Using Randconfig for Edge Devices

Abstract

The present invention discloses a kernel boot test method for enhancing bootability and stability for edge devices using Randconfig. The Randconfig tool is utilized to generate random kernel configuration files, and the generated configuration files are compiled and subjected to boot tests. For the unbootable configuration files, the config-bisect algorithm is employed for repair. The configuration item difference set is generated through the differences between the minimum default configuration file and the configuration file to be repaired, and the configuration items that cause boot failures are iteratively located and recorded in the critical configuration database. The repaired kernel is further subjected to stress tests through the fuzz testing module, and blacklists and whitelists are generated in combination with the device hardware resources to optimize the configuration items and improve the test coverage rate. The present invention improves the usability and stability of kernel boot tests for edge devices.

Description

Technical Field

[0001] The present invention relates to the technical field of Linux operating systems, and particularly relates to a kernel boot test method for enhancing bootability and stability by using Randconfig for edge devices. 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 still increasing with each version update. Each configuration item represents a specific functional module in the kernel, and its diversity and complexity make the kernel configuration problem theoretically analogous to the subset and subgroup problems in a high-dimensional configuration space. The search space of this problem grows exponentially, and it is difficult to cover all possible configuration combinations by manually writing test cases, resulting in potential problems often being discovered only in actual applications. Especially in the field of edge devices, the challenges of kernel configuration and testing are more prominent. They usually run in resource-constrained environments, such as low-power CPUs and limited memory, and require highly customized kernel configurations to balance functionality and resource consumption. In addition, the hardware platforms and application scenarios of edge devices are diverse, such as Internet of Things devices, smart sensors, and drones. The startup processes of these devices pose higher requirements for the reliability and stability of kernel configurations, and existing test tools are difficult to balance generality and specific scenario requirements.

[0003] Traditional kernel configuration methods (such as make config, 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. In recent years, research has focused on automated testing and optimizing test tools to improve coverage, but existing fuzz testing tools (such as Syzkaller) still have deficiencies in terms of 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 usually cannot be directly used for bootable kernel startup testing, and existing research on the application of Randconfig in kernel startup testing is also scarce.

[0004] At the same time, the unique requirements of edge devices further highlight the importance of improving kernel testing and kernel boot repair. The bootability and stability of the kernel are crucial for practical applications, but its resource-constrained characteristics limit the applicability of large-scale test 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 enhancing the bootability and stability of edge devices using Randconfig, which automatically generates and tests a large number of random kernel configurations to identify and repair the configuration items that cause kernel boot failures, and ultimately improves the stability and performance of the operating system kernel in edge devices. In view of the characteristics of limited resources, diverse hardware platforms, and complex application scenarios of edge devices.

[0006] A kernel boot test method for enhancing the bootability and stability of edge devices using Randconfig according to the present invention includes the following steps:

[0007] (1) Call the Randconfig toolchain through the configuration generation module to generate a specified number of kernel configuration files based on random seeds;

[0008] (2) Compile and perform a boot test on the configuration files generated in step (1) through the kernel repair module, and use the config-bisect algorithm to repair the unbootable configuration files;

[0009] (3) Perform fuzz testing on the repaired kernel through the data analysis module, dynamically generate blacklists and whitelists based on the device hardware resources to optimize the configuration, and record the key configuration item data to improve the test coverage rate

[0010] Further, in step (1), the random seeds are generated by calculating the microseconds of the system time; the configuration generation process includes randomly enabling / disabling boolean configuration items, randomly selecting values for numerical configuration items, and randomly selecting predefined values for string configuration items; the number of generated configuration files is 1 million to 2 million.

[0011] Further, the config-bisect algorithm in step (2) includes:

[0012] (21) Generate a configuration item difference set through the difference between the minimum default configuration file and the configuration file to be repaired;

[0013] (22) Divide the difference set into subsets for iterative testing, and locate the configuration items that cause boot failures through the dichotomy method;

[0014] (23) Record the successfully repaired configuration items in the key configuration database.

[0015] Further, the minimum default configuration file is generated through the `make olddefconfig` command, and the boot test is executed in the QEMU virtualization platform.

[0016] Further, the generation of the blacklist and whitelist in step (3) includes: obtaining device hardware information through a system interface; adding resource-consuming configuration items to the blacklist; adding lightweight schedulers and low-power management modules to the whitelist; dynamically updating the list rules based on fuzz testing results; where the hardware information includes: CPU architecture, memory capacity, network bandwidth; and the resource-consuming configuration items include: graphics drivers, complex file systems.

[0017] Further, it also includes: integrating a commit-bisect positioning tool to locate the code commit that causes the kernel startup failure through the Git bisect strategy; associating the repaired configuration items with historical commits to generate a traceable configuration item change record.

[0018] Further, the data analysis module further includes: performing syntax parsing on the Kconfig file and storing configuration items classified by menuconfig / choice / menu levels; outputting the classification results in JSON format for subsequent analysis of the impact of configuration items.

[0019] Further, the 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; boundary value testing of kernel startup parameters.

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

[0021] A storage medium according to the present invention stores a computer program. When the computer program is executed by a processor, it implements any one of the kernel boot testing methods for enhancing bootability and stability using Randconfig for edge devices.

[0022] 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 usage environment of the current specific device and meet its strict requirements for kernel startup time and stability. By using Randconfig to generate a large number of random kernel configuration files, performing kernel compilation and QEMU test startup, automatically repairing unbootable kernel configuration files, and performing fuzz testing on bootable kernel images. During the testing process, continuously record the key configuration items that affect kernel startup, and analyze the data to optimize the kernel configuration and testing process. Experimental results show that compared with traditional fuzz testing tools, this method performs better in terms of test coverage, vulnerability detection ability, and repair efficiency, and is particularly suitable for kernel optimization of edge devices and large-scale kernel development and testing scenarios. Description of the Drawings

[0023] Figure 1 is a flowchart of the present invention;

[0024] Figure 2 is a schematic diagram of the root file system creation process of the present invention;

[0025] Figure 3 is an example of the virtualization platform booting the kernel of the present invention;

[0026] Figure 4 is the execution flow of the config-bisect algorithm repair of the present invention. Detailed Implementation Manner

[0027] The present invention will be further explained and illustrated below in conjunction with the 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.

[0028] A kernel boot test method for enhancing bootability and stability using Randconfig for edge devices according to the present invention includes the following steps:

[0029] S1 As Figure 1 the configuration item generation module in, with the Linux source code of the target version as the basic input, and then run the make randconfig command to randomly generate 1.5 million random kernel configuration items. For the Randconfig command, it takes the microsecond number of the current system time by executing the algorithms located in / scripts / kconfig / confdata.c and / scripts / kconfig / conf.c, calculates the initial seed of the random function according to the microsecond number, and ensures that the random number sequence obtained each time is different to generate different kernel configurations; among them, 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 string options, a value is randomly selected from a predefined string list. The specific algorithm is as follows:

[0030] S2 The kernel repair module compiles the kernel according to the generated configuration file and performs a boot test 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.

[0031] For process (a), as Figure 2As shown, this invention takes arm64 (aarch64) as an example during the compilation and startup testing process. By setting up the compilation environment, using the GCC compiler to compile the kernel, and using an 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 the startup test of the current kernel configuration file at the end of the test task. Reading and analyzing this log can show the startup result of the configuration file generated by Randconfig this time. This invention uses the QEMU virtualization platform for kernel boot testing. Figure 3 Shows an example of a kernel boot test using QEMU.

[0032] Randconfig provides extensive test coverage but also generates a high degree of uncertainty. In the exponentially growing space of configuration options, most combinations have not been verified or optimized, and there may be conflicts or missing dependencies. Therefore, in most cases, after compiling the kernel and mounting it to the root file system, the generated.config file will not be able to start successfully. To enable these kernels to start, the key is to repair and adjust the configuration items in the.config file.

[0033] For process (b), the core of kernel repair to be bootable is based on the changes of the configuration items in the kernel configuration file.config. Figure 4 Shows a complete repair process, as Figure 4 , and the specific steps are as follows:

[0034] a1 Prepare Good-config. The source of Good-config can be any bootable configuration file. Considering the differences in bootable configuration files for each platform and the need to quickly obtain a bootable configuration file to meet the requirements of automated testing, this invention selects the make olddefconfig command provided by the Linux kernel to generate the minimum default configuration file based on the current system platform, and this configuration file can be started.

[0035] a2 Obtain the configuration item difference set config-temp. Compare the differences between Good-config and Bad-config to get the configuration items that are in Good-config but not in Bad-config, and the configuration items in Good-config that modify Bad-config. Record these configuration items in the config-temp set.

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

[0037] Test the startup result of a4 with A + Bad-config and start a loop. The steps are as follows:

[0038] a41 If the startup is successful, it means there is an over-addition. Then divide A into two halves A / 2 on the basis of A, test the startup result of A / 2 + Bad-config until it cannot be started. Record the configuration file bootable-config and configuration items bootable-items before the non-startup, and end the loop.

[0039] a42 If the startup of A + Bad-config fails, then add B and test the startup result of A + B + Bad-config. If it can be started, divide B into two halves on the basis of B and test the startup result of A + B / 2 + Bad-config until it cannot be started. Similarly, record bootable-config and configuration items bootable-items, and end the loop.

[0040] a5 Write bootable-config to a file to obtain the repaired bootable configuration file.

[0041] a6 Record the list of newly added and deleted configuration items in this repair.

[0042] In the Kconfig classification part of the S3 data analysis module, the present invention designs a general Kconfig syntax classification algorithm to analyze the Kconfig configuration file obtained in the previous section and classify the common configuration item files that can be started and cannot be started. The specific steps are as follows:

[0043] S31 Initialize the configuration item classification result config_typed_dict to be empty;

[0044] S32 Read the first line in the content of the Kconfig file according to kconfig_filepath;

[0045] S33 If the end flag of the file is not read, enter the parsing;

[0046] S331 If this line matches the syntax keywords menuconfig, choice, menu, then parse to a new classification name c_new according to the syntax rules. If the current classification c_current exists, make the new classification c_new a subclass of the current classification c_current, set the current classification as the new classification c_current = c_new, and store the classification in config_typed_dict;

[0047] If this line matches the syntax "config", parse the configuration item name "config_item" according to the syntax rules, store "config_item" in the category "c_current", and record it in "config_typed_dict".

[0048] If this line matches the syntax keyword "source", match and parse the new Kconfig path "new_kconfig_filepath" according to the syntax rules, set "kconfig_filepath = new_kconfig_filepath", and go to step S331.

[0049] Read the next line of the Kconfig file, and go back to step S333 to continue the loop.

[0050] S34 Save the classification result "config_typed_dict" and output it in JSON format to a physical file.

[0051] The black and white list part in the data analysis module is designed to automatically optimize the kernel configuration according to the specific resource requirements of the device (such as a 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:

[0052] First, the module analyzes the resource status of the current 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 interfaces (lscpu, free, and ifconfig).

[0053] Then, based on the data before and after each kernel repair, further analyze the impact of the current kernel configuration on device resources, and automatically add configuration items such as unnecessary graphics processing modules, virtualization support, and large file systems to the block list. For example, disable high-performance graphics drivers, larger or complex file systems (ext4, xfs), and unused hardware modules to save memory and processing power. According to the requirements of the edge device, add lightweight schedulers (CFS scheduler), low-power management modules, and simplified network protocol stacks to the allow list to improve the device's response speed and resource utilization rate. After each kernel repair, the module will automatically modify the kernel configuration file according to the current device's resource status and optimization strategy. The generated configuration file will be automatically tested by a script to ensure that the repaired kernel can start and run efficiently on the edge device. After the kernel configuration is adjusted, the module will run the kernel test again and record the performance data to feedback the optimization results. According to 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.

[0054] Through this module, automated kernel optimization based on edge device resources can be achieved, minimizing the waste of hardware resources by the kernel and improving the operating efficiency of edge devices under low-power and limited-resource conditions.

[0055] The selected baseline Linux kernel version in this 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 runs on OpenEuler 20.03-LTS-SP1. As a rising star among domestic operating systems, this system is known for its good support for resource-constrained devices and high-performance features. 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, to improve data processing capabilities and operating efficiency, a part of the server-side logic is written in Crystal and Ruby to handle the requirements of data transmission and status synchronization in edge device scenarios.

[0056] Table 1 Kernel Boot Results before and after Repair

[0057] ;

[0058] Randconfig in this invention is used to randomly generate a configuration file to create 1.5 million kernels for repair. The boot results before and after repair are shown in Table 1. The 5.10 version kernel with a randomly generated configuration file is used as the input for kernel repair. The success rate of directly booting the kernel from the configuration file generated by Randconfig is approximately 5% - 10%. After the system developed based on the enhanced kernel boot test method in this paper is repaired, the success rate of booting the same batch of kernels reaches 91.263%, and the repair effect is remarkable.

[0059] Table 2 Comparison of Error Repair Times

[0060] ;

[0061] Kernel boot anomalies 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 newly introduced features or the deletion of features that affect the kernel boot process. To quickly locate the critical commit that causes this problem, this invention combines the improved kernel boot test method with the binary search strategy of git to create a commit-splitting anomaly commit localization tool, as Figure 1As shown in the implement part. To verify the effectiveness of the anomaly submission localization tool (commit-split) in actual kernel development, an experiment was conducted to simulate the collaborative development process of the Linux kernel, aiming to test the ability of this tool to locate kernel boot failure problems caused by configuration file errors or code changes. First, pull the main branch of torvalds / linux. The latest commit of this branch was used as the initial baseline for the experiment to ensure that it could be successfully compiled and booted in the environment described above. Second, to simulate the actual collaborative development scenario, a series of commits were designed to deliberately introduce bugs that would cause the kernel to fail to boot. Two different types of commits were made during the experiment: kernel commits that could be booted (good commits): A set of tested kernel versions that could be booted normally were provided as the baseline for good commits. Commits caused by misconfigurations (bad commits): Subsequent commits deliberately introduced incorrect configuration files, resulting in the kernel failing to boot. Such errors included the configuration of missing key modules and the introduction of incompatible options, thus forming bad commits. These commits formed a commit sequence containing multiple bad commits to simulate kernel boot failures that might occur during the development process. After constructing the bad commit sequence, the commit-bisect tool was used to automatically locate the kernel boot failure. The experiment simulated multiple commit sequences, and this tool successfully located each commit introducing errors, verifying its effectiveness in kernel boot failures. During the experiment, this tool significantly reduced the time cost of problem localization. The specific results of the experiment are shown in Table 2. This experiment demonstrated the significant advantages of the commit-split tool in finding bad commits. Compared with the traditional linear search method of manual debugging, this tool used binary search, greatly reducing the number of commits to be tested and reducing the time complexity from O(n) to O(log n). In addition, the automated process of this tool reduced the need for manual intervention, quickly located the problem commit, and improved the debugging efficiency of the kernel development process.

[0062] Table 3 Comparison of Features of Popular Testing Tools

[0063] ;

[0064] As shown in Table 3, it shows the features of common fuzz testing tools related to Linux kernel testing, but the features of automated testing and fixing kernel configuration items are unique to the enhanced fuzz testing tool designed in the present invention.

[0065] Table 4 Comparison of the Fuzz Testing Tool of the Present Invention with Syzkaller

[0066] ;

[0067] Compare the performance of the fuzz testing tool designed in the present invention with that of the traditional fuzz testing tool (Syzkaller). Evaluate the performance from four aspects: vulnerability detection ability, configuration coverage rate, repair ability, and resource consumption. The experimental results are shown in Table 4. Under the same test environment and time constraints, the fuzz testing tool designed in the present invention discovered a total of 220 potential vulnerabilities, an increase of 46.7% compared to the 150 vulnerabilities discovered by Syzkaller. Using LCONV to obtain the test coverage rate, the test coverage rate of this paper reached 95%, higher than 70% of Syzkaller. 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 unbootable kernel within 91% of the time, which further ensures that fuzz testing can run smoothly under multiple kernel configurations. In terms of resource consumption, the system of the present invention ran for 26.5 hours within 24 hours, and the CPU utilization rate was 82%. While the running time of Syzkaller was 25 hours, and the CPU utilization rate was 80%. Compared with Syzkaller, the enhanced fuzz testing tool designed in the present invention can discover more potential vulnerabilities without increasing resource occupancy. This experiment proves that the fuzz testing tool combined with the enhanced kernel boot testing method has significant advantages in terms of test coverage rate, vulnerability detection ability, repair efficiency, etc.

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) The Randconfig toolchain is called through the configuration generation module to generate a specified number of kernel configuration files based on random seeds. The minimum default configuration file is generated through the `make olddefconfig` command, and the startup test is performed in the QEMU virtualization platform. (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; wherein the config-bisect algorithm 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; (3) Perform fuzz testing on the repaired kernel through the data analysis module, dynamically generate blacklists and whitelists based on the device hardware resources to optimize the configuration, and record key configuration item data to improve test coverage; perform syntax parsing on the Kconfig file, and store configuration items according to the menuconfig / choice / menu hierarchy; output the classification results in JSON format for subsequent configuration item impact analysis.

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 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.

4. 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.

5. 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.

6. 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 5.

7. 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 5.

Images