Fuzzy test input generation method based on characteristic unification and related equipment

Abstract

The invention relates to the technical field of kernel fuzz testing, and provides a fuzz test input generation method based on characteristic unification and related equipment, the method comprises the following steps: generating a function call graph and a plurality of control flow graphs of a target system, and integrating the function call graph and all the control flow graphs to obtain an inter-program control flow graph; constructing a kernel code calling chain based on the inter-program control flow diagram; carrying out characteristic unified representation modeling based on the kernel configuration file and the kernel code call chain of the target system, and generating a configuration code relation mapping table; extracting related information of the characteristic related interface function according to the kernel code call chain, and performing grammar conversion based on the related information to generate a system call test protocol template of the characteristic related interface function; and generating fuzzy test input of the target system based on the system call test protocol template and the configuration code relation mapping table. According to the method provided by the invention, the correlation between kernel characteristic configuration and fuzzy test input can be improved.

Description

Technical Field

[0001] The present application relates to the field of kernel fuzz testing technology, and in particular to a fuzz testing input generation method based on feature unification and related equipment. Background Art

[0003] The open source community kernel customization features are crucial to the stable development of the open source community and the vendors participating in the community, and their quality and safety must be effectively guaranteed. With the continuous addition of new kernel customization features, new kernel defects are also increasing. Current open source operating system projects still face many challenges in kernel quality assurance, especially the lack of technical capabilities for kernel defect detection in the face of kernel customization features.

[0004] Kernel fuzz testing is an automated operating system kernel vulnerability detection technology. The quality of fuzz testing input has a huge impact on test execution. Generating targeted test input that meets the kernel feature function logic can greatly improve the test effect.

[0005] However, current targeted fuzz testing technologies such as targeted kernel fuzz testing generate test cases based on existing system call test specification templates, ignoring the high coupling between kernel feature configuration and code, failing to effectively combine use case description and feature representation, and failing to build test specification templates that meet the application logic of kernel features. They lack the ability to model targeted test inputs for kernel feature characteristics. The kernel customization features of open source operating systems involve multiple dimensions of configuration dependencies, functional logic, and configuration combinations and interaction logic. These features are highly coupled during implementation, and there may be large differences in requirements and configurations in different application scenarios, making it difficult for existing fuzz testing methods to achieve effective test coverage. Existing test input generation methods cannot accurately reflect the complex relationship between kernel functions, configurations, and application scenarios, resulting in poor correlation between fuzz test inputs and kernel features. Summary of the invention

[0006] The present application provides a fuzzy test input generation method based on feature unification and related devices, which can solve the problem of poor correlation between fuzzy test input and kernel features.

[0007] In a first aspect, an embodiment of the present application provides a method for generating fuzzy test input based on feature unification, the method comprising: Generate a function call graph and multiple control flow graphs of the target system, and integrate the function call graph and all control flow graphs to obtain an inter-program control flow graph; multiple nodes in the function call graph correspond one-to-one to multiple kernel source code functions of the target system, and the edges between the nodes are the call relationships between the corresponding two kernel source code functions; multiple control flow graphs correspond one-to-one to multiple kernel source code functions; multiple nodes in the control flow graph correspond one-to-one to multiple basic blocks in the corresponding kernel source code functions, and the edges between the nodes are the control relationships between the corresponding two basic blocks; Construct kernel code call chains based on inter-program control flow graphs; kernel code call chains are used to describe the calling relationships between kernel source code functions and the control relationships between basic blocks; Based on the kernel configuration file and kernel code call chain of the target system, a unified feature representation model is performed to generate a configuration code relationship mapping table; the configuration code relationship mapping table is used to describe the dependency relationship between all kernel feature configurations in the kernel configuration file and the kernel source code corresponding to each kernel feature configuration, and the kernel source code corresponds to the kernel source code function or basic block; Extract relevant information of the feature-related interface function according to the kernel code call chain, perform syntax conversion based on the relevant information, and generate a system call test specification template for the feature-related interface function; the relevant information is used to describe the data types and constraints of the input parameters and return parameters of the feature-related interface function, and the feature-related interface function is a kernel source code function; A fuzzy test input of a target system is generated based on a system call test specification template and a configuration code relationship mapping table; the fuzzy test input is a test case for testing a kernel feature configuration.

[0008] Optionally, a unified feature representation model is performed based on the kernel configuration file and kernel code call chain of the target system to generate a configuration-code relationship mapping table, including: According to the kernel configuration file, all kernel feature configurations of the target system, the dependencies between all kernel feature configurations, and the kernel source code corresponding to each kernel feature configuration are identified in layers; A configuration-code relationship mapping table is generated based on the dependencies among all kernel source codes, all kernel feature configurations, and the kernel code call chain.

[0009] Optionally, extract relevant information about feature-related interface functions based on the kernel code call chain, including: The calling path of the feature-related interface function of the target system in the kernel code calling chain is traced to obtain relevant information of the feature-related interface function.

[0010] Optionally, perform syntax conversion based on relevant information to generate a system call test specification template for feature-related interface functions, including: Perform language standardization on the relevant information to obtain standard relevant information in a specific description language format that complies with kernel fuzz testing; Generates a system call test specification template for feature-related interface functions based on specification-related information.

[0011] Optionally, generate fuzz test input of the target system based on the system call test specification template and the configuration code relationship mapping table, including: Get the seed case for kernel fuzz testing of the target system; Analyze the coverage distribution of seed use cases in kernel fuzz testing, and determine the feature test specification type that needs to be inserted based on the coverage distribution and configuration code relationship mapping table, and determine the insertion position of the feature test specification type in the seed use case based on the coverage distribution; coverage distribution is used to describe the code covered by the seed use case; Generate the specification parameters of the feature test specification type based on the system call test specification template, insert the specification parameters into the seed case according to the insertion position, and obtain the fuzzy test input of the target system.

[0012] Optionally, based on the coverage distribution and configuration code relationship mapping table, the feature test specification type to be inserted is determined, including: For the kernel feature configuration in the configuration code relationship mapping table, if the code of the feature-related interface function corresponding to the kernel feature configuration is not included in the coverage distribution, the kernel feature configuration is used as the target configuration to obtain a feature test specification type for indicating testing the target configuration.

[0013] Optionally, generate specification parameters of feature test specification type based on the system call test specification template, including: Generate specification parameters of a feature test specification type according to data types and constraints of input parameters and return parameters of a feature-related interface function corresponding to a target configuration in a system call test specification template.

[0014] In a second aspect, an embodiment of the present application provides a fuzzy test input generation device based on feature unification, comprising: An integration module is used to generate a function call graph and multiple control flow graphs of the target system, and integrate the function call graph and all control flow graphs to obtain an inter-program control flow graph; multiple nodes in the function call graph correspond one-to-one to multiple kernel source code functions of the target system, and the edges between the nodes are the call relationships between the corresponding two kernel source code functions; multiple control flow graphs correspond one-to-one to multiple kernel source code functions; multiple nodes in the control flow graph correspond one-to-one to multiple basic blocks in the corresponding kernel source code functions, and the edges between the nodes are the control relationships between the corresponding two basic blocks; A construction module is used to construct a kernel code call chain based on the inter-program control flow graph; the kernel code call chain is used to describe the calling relationship between kernel source code functions and the control relationship between basic blocks; The first generation module is used to perform unified feature representation modeling based on the kernel configuration file and kernel code call chain of the target system, and generate a configuration code relationship mapping table; the configuration code relationship mapping table is used to describe the dependency relationship between all kernel feature configurations in the kernel configuration file and the kernel source code corresponding to each kernel feature configuration, and the kernel source code corresponds to the kernel source code function or basic block; A syntax conversion module is used to extract relevant information of the feature-related interface function according to the kernel code call chain, and perform syntax conversion based on the relevant information to generate a system call test specification template for the feature-related interface function; the relevant information is used to describe the data types and constraints of the input parameters and return parameters of the feature-related interface function, and the feature-related interface function is a kernel source code function; The second generation module is used to generate a fuzzy test input for the target system based on the system call test specification template and the configuration code relationship mapping table; the fuzzy test input is a test case for testing the kernel feature configuration.

[0015] In a third aspect, an embodiment of the present application provides a terminal device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the above-mentioned feature-unified based fuzzy test input generation method when executing the above-mentioned computer program.

[0016] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program, and when the computer program is executed by a processor, the above-mentioned feature-unified based fuzzy test input generation method is implemented.

[0017] The above solution of the present application has the following beneficial effects: In an embodiment of the present application, a function call graph and multiple control flow graphs of a target system are generated, and the function call graph and all control flow graphs are integrated to obtain an inter-program control flow graph, and then a kernel code call chain is constructed based on the inter-program control flow graph, and then a unified characteristic representation modeling is performed based on the kernel configuration file of the target system and the kernel code call chain, and a configuration code relationship mapping table is generated, and then the relevant information of the characteristic-related interface function is extracted according to the kernel code call chain, and a syntax conversion is performed based on the relevant information to generate a system call test specification template for the characteristic-related interface function, and finally a fuzzy test input of the target system is generated based on the system call test specification template and the configuration code relationship mapping table. Among them, the unified characteristic representation modeling of the kernel configuration file and the kernel code call chain can deeply analyze the dependency relationship of the kernel characteristic configuration, and in combination with the implementation logic of the code, a configuration code relationship mapping table that integrates the information of the two is constructed, and the relationship between the kernel characteristic configuration and the code is effectively characterized, and the generation of fuzzy test input based on the configuration code relationship mapping table can closely combine the relationship between the kernel characteristic configuration and the fuzzy test input, and improve the correlation between the two.

[0018] Other beneficial effects of the present application will be described in detail in the subsequent specific implementation section. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0020] Figure 1 A flowchart of a method for generating fuzzy test input based on feature unification provided in an embodiment of the present application; Figure 2 A flowchart of generating a configuration code relationship mapping table provided in an embodiment of the present application; Figure 3 A flowchart of generating a system call test specification template provided in an embodiment of the present application; Figure 4 A flowchart of generating fuzzy test input provided by an embodiment of the present application; Figure 5 A schematic diagram of the structure of a fuzzy test input generation device based on feature unification provided in an embodiment of the present application; Figure 6 A schematic diagram of the structure of a terminal device provided in one embodiment of the present application. DETAILED DESCRIPTION

[0021] In the following description, specific details such as specific system structures, technologies, etc. are provided for the purpose of illustration rather than limitation, so as to provide a thorough understanding of the embodiments of the present application. However, it should be clear to those skilled in the art that the present application may also be implemented in other embodiments without these specific details. In other cases, detailed descriptions of well-known systems, devices, circuits, and methods are omitted to prevent unnecessary details from obstructing the description of the present application.

[0022] It should be understood that when used in the present specification and the appended claims, the term "comprising" indicates the presence of described features, wholes, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components and / or combinations thereof.

[0023] It should also be understood that the term “and / or” used in the specification and appended claims refers to any and all possible combinations of one or more of the associated listed items, and includes these combinations.

[0024] As used in the specification and appended claims of this application, the term "if" can be interpreted as "when" or "uponce" or "in response to determining" or "in response to detecting", depending on the context. Similarly, the phrase "if it is determined" or "if [described condition or event] is detected" can be interpreted as meaning "uponce it is determined" or "in response to determining" or "uponce [described condition or event] is detected" or "in response to detecting [described condition or event]", depending on the context.

[0025] In addition, in the description of the present application specification and the appended claims, the terms "first", "second", "third", etc. are only used to distinguish the descriptions and cannot be understood as indicating or implying relative importance.

[0026] References to "one embodiment" or "some embodiments" etc. described in the specification of this application mean that one or more embodiments of the present application include specific features, structures or characteristics described in conjunction with the embodiment. Therefore, the statements "in one embodiment", "in some embodiments", "in some other embodiments", "in some other embodiments", etc. that appear in different places in this specification do not necessarily refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in other ways. The terms "including", "comprising", "having" and their variations all mean "including but not limited to", unless otherwise specifically emphasized in other ways.

[0027] In view of the problem of poor correlation between existing fuzzy test input and kernel features, an embodiment of the present application provides a fuzzy test input generation method based on feature unification, which generates a function call graph and multiple control flow graphs of a target system, integrates the function call graph and all control flow graphs, obtains an inter-program control flow graph, then builds a kernel code call chain based on the inter-program control flow graph, and then performs feature unified characterization modeling based on the kernel configuration file of the target system and the kernel code call chain, generates a configuration code relationship mapping table, then extracts relevant information of feature-related interface functions according to the kernel code call chain, and performs syntax conversion based on the relevant information to generate a system call test specification template for the feature-related interface function, and finally generates the fuzzy test input of the target system based on the system call test specification template and the configuration code relationship mapping table. Among them, the kernel configuration file and the kernel code call chain are subjected to feature unified characterization modeling, which can deeply analyze the dependency relationship of the kernel feature configuration, and combine the implementation logic of the code to construct a configuration code relationship mapping table that integrates the information of the two, effectively characterizes the relationship between the kernel feature configuration and the code, and generates the fuzzy test input based on the configuration code relationship mapping table, which can closely combine the relationship between the kernel feature configuration and the fuzzy test input, and improve the correlation between the two.

[0028] The following is an explanation of the relevant professional terms of this application.

[0029] Kernel fuzz testing is an automated operating system kernel vulnerability detection technology that injects a large number of unexpected system call sequence inputs into the operating system kernel, simulating different usage scenarios and system boundary conditions to discover potential code anomalies and potential defects. It is often used in software security research.

[0030] Unified feature representation is to analyze the operating system kernel code and configuration files through program analysis technology to construct a structured representation of the dependency relationship between kernel feature configuration and code implementation. It aims to eliminate the "semantic gap" between kernel feature configuration and actual code implementation, so that the test input can accurately reflect the functional requirements and configuration logic of the kernel features, thereby providing support for efficient fuzz testing.

[0031] The system call test specification template is used to define and generate the format and rules of the test input to ensure that the input data meets the functional requirements and configuration constraints of the kernel features.

[0032] Static analysis is a software analysis technique that detects potential defects or vulnerabilities by checking the source code or compiled intermediate representation of the program without actually running the program. It is mainly used to find logical errors, coding standard problems and security vulnerabilities in the code, and is often used in the early stages of software development to improve software quality.

[0033] A function call graph (CG) is a graph structure that represents the call relationship between functions in a program. Each node in the graph represents a function in the program, and an edge represents a function calling another function. Through the function call graph, developers can intuitively see the call chain between functions in the program, helping to analyze the structure and logic of the program. CG is often used for static analysis, performance optimization, and vulnerability detection.

[0034] A control flow graph (CFG) is a graph structure that represents the control flow relationship between basic blocks in a program. A basic block is a code segment without jumps or branches. Each node in the graph represents a basic block, and the edge represents the execution path of the control flow from one basic block to another. CFG is used to reveal control structures such as branches and loops in a program, and is widely used in scenarios such as code optimization, path analysis, and vulnerability detection.

[0035] The Interprocedural Control Flow Graph (ICFG) is an extension of the Control Flow Graph (CFG). It considers both the control flow within a function and the control flow relationship between different functions. ICFG combines the function call graph (CG) with the Control Flow Graph (CFG) to display the control flow path across functions. This graph can provide a global view to help developers analyze the execution paths between different functions and is widely used in complex scenarios such as program analysis, symbolic execution, and vulnerability detection.

[0036] Kernel source code functions refer to the various functions in the operating system kernel, which are responsible for the core functions of the operating system, such as process scheduling, memory management, hardware control, file system management, etc.

[0037] Kernel feature configuration is a configuration option used to control system features. Features refer to various functions or capabilities supported by the operating system, such as hardware support, kernel modules, scheduling policies, memory management policies, etc.

[0038] Feature-related interface functions refer to interface functions in the code path that support or implement features.

[0039] A test case is a description of a test task for a software or system, reflecting the test plan, method, technology and strategy. Its contents include test objectives, test environment, input data, test steps, expected results, test scripts, etc., and finally form a document.

[0040] Next, the feature-unified fuzzy test input generation method provided in this application is exemplified.

[0041] like Figure 1As shown, the fuzzy test input generation method based on feature unification provided by the present application includes the following steps: Step 11, generate a function call graph and multiple control flow graphs of the target system, and integrate the function call graph and all control flow graphs to obtain an inter-program control flow graph.

[0042] The multiple nodes in the above function call graph correspond one-to-one to the multiple kernel source code functions of the target system, the edges between the nodes are the call relationships between the two corresponding kernel source code functions, the multiple control flow graphs correspond one-to-one to the multiple kernel source code functions, the multiple nodes in the control flow graph correspond one-to-one to the multiple basic blocks in the corresponding kernel source code functions, and the edges between the nodes are the control relationships between the two corresponding basic blocks. The above target system is the system to be tested, such as the server operating system of Alibaba Cloud, etc. The kernel source code functions can be list management functions, kernel library functions, etc.

[0043] In some embodiments of the present application, when integrating the function call graph and all control flow graphs, the function call graph and all control flow graphs are integrated into the same graph according to the correspondence between the control flow graph and the kernel source code function to obtain an inter-program control flow graph.

[0044] Step 12: construct a kernel code call chain based on the inter-program control flow graph.

[0045] The above kernel code call chain is used to describe the calling relationship between kernel source code functions and the control relationship between basic blocks.

[0046] Specifically, according to the calling relationship between all kernel source code functions described by the inter-program control flow graph (ICFG), a part of the kernel code call chain is generated, such as function A calling function B, function B calling function C; then, based on the calling relationship between all basic blocks described by the ICFG, another part of the kernel code call chain is generated to supplement the control flow path inside the function, such as basic block 1 calling basic block 2 in function A, and basic block 2 calling basic block 3. Finally, these two parts are combined into a complete kernel code call chain.

[0047] Step 13: Perform unified feature characterization modeling based on the kernel configuration file and kernel code call chain of the target system to generate a configuration-code relationship mapping table.

[0048] The above configuration code relationship mapping table is used to describe the dependency relationship between all kernel feature configurations in the kernel configuration file and the kernel source code corresponding to each kernel feature configuration, and the kernel source code corresponds to the kernel source code function or basic block.

[0049] In some embodiments of the present application, the above-mentioned step of performing unified characteristic representation modeling based on the kernel configuration file and the kernel code call chain of the target system and generating a configuration code relationship mapping table includes: The first step is to identify all kernel feature configurations of the target system, the dependencies between all kernel feature configurations, and the kernel source code corresponding to each kernel feature configuration in a hierarchical manner based on the kernel configuration file.

[0050] It should be noted that the kernel configuration file may be a Kconfig file.

[0051] Specifically, the specific process of this step includes: 1. Parsing Kconfig file First, extract all configuration options (i.e. kernel feature configuration) and their dependencies from the kernel's Kconfig file. The Kconfig file is the core of the Linux kernel configuration system and contains the definition of each configuration option, its dependencies (such as depends on and select), and their description information.

[0052] The specific steps are: Iterate over all config entries in Kconfig files, extracting the names of configuration options, dependencies (such as depends on statements), and choices (such as select statements).

[0053] 2. Build a directed graph of configuration options After obtaining all configuration options and their dependencies, these relationships are constructed into a dependency directed graph.

[0054] Node: Each node in the dependency directed graph represents a configuration option (e.g. CONFIG_A).

[0055] Directed edge: If a configuration option B depends on configuration option A, then there is a directed edge from the node corresponding to B to the node corresponding to A.

[0056] Storage method: Adjacency list or adjacency matrix data structures can be used to store dependency directed graphs.

[0057] This graph structure can intuitively represent the dependencies between all configuration options, and can be subsequently parsed layer by layer based on the graph.

[0058] 3. Hierarchical recognition through topological sorting In order to identify the hierarchical relationship of configuration options, you can perform topological sorting on the dependency directed graph and organize the configuration options layer by layer according to the dependency hierarchy. The specific steps are as follows: Initialize layer 0: First find all nodes in the graph that have no dependencies (i.e. nodes with in-degree 0). These nodes belong to layer 0 because they do not depend on any other configuration options.

[0059] Remove the 0th-level nodes: Remove the 0th-level nodes and their out-edges from the graph, and update the in-degree information of the remaining nodes.

[0060] Identify the next layer of nodes: Among the remaining nodes, continue to look for nodes with in-degree 0, which belong to the first layer.

[0061] Repeat the above process: remove nodes layer by layer and update the in-degree information until all nodes are assigned to a certain layer.

[0062] Ultimately, the nodes in the dependency directed graph will be organized hierarchically, with nodes at higher levels representing more complex configuration options.

[0063] Example: For the following dependencies: CONFIG_C depends on CONFIG_B CONFIG_B depends on CONFIG_A CONFIG_D depends on CONFIG_A Stratification results: Layer 0: CONFIG_A (no dependencies) Layer 1: CONFIG_B, CONFIG_D (depends on CONFIG_A) Layer 2: CONFIG_C (depends on CONFIG_B) 4. Associate configuration options with kernel source code After completing the hierarchical identification of configuration options, each configuration option needs to be associated with the kernel source code. This is usually done by parsing the Makefile file. The specific steps are as follows: Traverse the Makefile files in the kernel source directory and find the compilation instructions related to the configuration options, for example: ; ; In this example, CONFIG_A corresponds to the kernel source code module_a.o, and CONFIG_B corresponds to the kernel source code module_b.o.

[0064] Establish a mapping relationship between the parsed configuration options and their corresponding kernel source codes.

[0065] When parsing layer by layer, start from the 0th level configuration options and gradually associate higher-level configuration options with their corresponding source code modules to ensure that the dependency chain is complete and clear.

[0066] 5. Generate hierarchical dependency mapping table Finally, based on the previous parsing results, a hierarchical dependency mapping table is generated, recording in detail: Configuration Options: The name of each configuration option.

[0067] Dependency level: The level to which the configuration option belongs.

[0068] Dependencies: other configuration options that a configuration option depends on.

[0069] Associated source code: kernel source code corresponding to the configuration option.

[0070] The second step is to generate a configuration-code relationship mapping table based on the dependencies between all kernel source codes, all kernel feature configurations, and the kernel code call chain.

[0071] Specifically, when generating the configuration code relationship mapping table, the kernel code call chain is used to analyze the call paths between the functions in the kernel source code corresponding to the configuration options (kernel feature configuration), and merge the call path information with the dependency information obtained in the previous step to obtain the configuration code relationship mapping table. For example, the call paths of multiple functions enabled by a certain configuration option can be captured based on the kernel code call chain, and further associated with other functions or code segments that are called. This association relationship can more accurately reflect the degree of coupling between the configuration options and the code implementation, thereby building a comprehensive configuration code mapping.

[0072] The steps of generating the configuration code relationship mapping table are described below with reference to a specific example.

[0073] like Figure 2As shown in the figure, on the one hand, an inter-process control flow graph ICFG is constructed based on the kernel source code file. The ICFG includes CG and multiple CFGs. In CG, main, a, b, c, d, and e all represent kernel source code functions. 0 represents the starting point of the function or the initial state that has not been called. 1, 2, and 3 all represent the hierarchical number of the call path. N / A represents a function without further calling relationship. CFG (a) and CFG (b) represent the CFGs corresponding to kernel source code function a and kernel source code function b respectively. a and c in CFG represent the numbers of basic blocks. Then, a kernel code call chain is constructed, and arrows represent call relationships or control relationships. On the other hand, according to the kernel configuration file, the Makefile file (the Makefile will specify which source code files belong to which modules, and will contain compiler options, link options and other information) is configured and mapped and extracted. Then, the dependency relationship is obtained through configuration dependency analysis. The dependency relationship and the kernel code call chain are characterized and modeled to obtain a configuration-code relationship mapping table. Figure 2 middle , It is a mapping expression between configuration options and target files, and defines the association rules between kernel features and specific source code files. CONFIG_TREE_RCU, CONFIG_TREE_EXPERT, CONFIG_FORCE_TASKS, and CONFIG_FORCE_RUDE_RCU are all configuration options. The arrows between configuration options represent dependency relationships. The code "#inculde <linux spinlock>" indicates the kernel synchronization mechanism file that may be introduced by some configuration options, "rcu_pending rcu_momentary_dyntick" indicates the kernel operation or status flag that may be associated with some configuration options, and the multiple lines of code corresponding to the configuration-code relationship mapping table in the figure are part of the configuration-code relationship mapping table. The example is used to describe the association between configuration options and kernel code implementation.

[0074] Step 14, extracting relevant information of the feature-related interface function according to the kernel code call chain, and performing syntax conversion based on the relevant information to generate a system call test specification template for the feature-related interface function.

[0075] The above related information is used to describe the data types and constraints of the input parameters and return parameters of the feature-related interface functions. The feature-related interface functions are kernel source code functions.

[0076] In some embodiments of the present application, the steps of extracting relevant information of the feature-related interface function according to the kernel code call chain, performing syntax conversion based on the relevant information, and generating a system call test specification template for the feature-related interface function include: The first step is to trace the calling path of the feature-related interface function of the target system in the kernel code calling chain to obtain the relevant information of the feature-related interface function.

[0077] Exemplarily, through semantic static analysis, the calling path of the feature-related interface function in the kernel code calling chain is traced to obtain the data types and constraints of the input parameters and return parameters of the feature-related interface function.

[0078] It should be noted that data types are used to define the legal type range of input and output parameters, such as int, struct tcp_info, etc. Constraints limit the legal value range of data, such as input parameters cannot be NULL, return values ​​must be greater than 0, etc.

[0079] The second step is to standardize the relevant information in language to obtain the relevant information in a specific description language format that conforms to kernel fuzz testing.

[0080] It should be noted that the extracted data types and constraints are mapped to the syntax of the fuzzy test description language. The specification-related information describes the operation type (such as READ, WRITE), resource type (such as TCP connection) and constraint rules (such as parameter range 0 < x < 1000) of the feature-related interface function.

[0081] The third step is to generate a system call test specification template for feature-related interface functions based on specification-related information.

[0082] Specifically, a data plane and a control plane are constructed according to specification-related information, and the data plane and the control plane are integrated to obtain a system call test specification template.

[0083] Exemplarily, the data plane is used to generate a data resource interface, describing the structure, legal type and value range of the input data, such as: config=initTCP { src_port=1024, dest_port=80}; the control plane is used to generate a feature configuration parameter range, define configuration options and test boundary conditions, such as: config=4sTCP { MAX_RETRY=5, TIMEOUT=30}.

[0084] This step is illustrated below with reference to a specific example.

[0085] The process of generating a system call test specification template is as follows Figure 3 As shown, the function call path is traced according to the configuration code call chain (i.e., the kernel code call chain) to obtain the structure type and constraints (i.e., data types and constraints), and then syntax conversion is performed to obtain the test specification of the fusion feature configuration (i.e., the system call test specification template). Figure 3 The code in the box corresponding to the configuration code call chain is the code of the kernel source code function, the arrow is the calling relationship of the function, the code of the structure type and constraint part is the code that describes the data type and constraint conditions, and the code of the test specification part is the code of the system call test specification template.

[0086] Step 15, generating a fuzzy test input for the target system based on the system call test specification template and the configuration code relationship mapping table.

[0087] The above fuzz test input is a test case used to test the kernel feature configuration.

[0088] In some embodiments of the present application, the step of generating the fuzzy test input of the target system based on the system call test specification template and the configuration code relationship mapping table includes: The first step is to obtain the seed case for kernel fuzz testing of the target system.

[0089] The second step is to analyze the coverage distribution of the seed use case in the kernel fuzz test, and determine the feature test specification type that needs to be inserted based on the coverage distribution and configuration code relationship mapping table, and determine the insertion position of the feature test specification type in the seed use case according to the coverage distribution.

[0090] The above coverage distribution is used to describe the code covered by the seed use case.

[0091] Specifically, the specific process of determining the type of feature test protocol that needs to be inserted based on the coverage distribution and the configuration code relationship mapping table is as follows: for the kernel feature configuration in the configuration code relationship mapping table, if the code of the feature-related interface function corresponding to the kernel feature configuration is not included in the coverage distribution, then the kernel feature configuration is used as the target configuration to obtain the feature test protocol type used to indicate the test of the target configuration.

[0092] Exemplary, Coverage Distribution Analysis: Perform coverage analysis on historical test cases to extract which codes have been covered and which have not yet been triggered. For example, code coverage analysis found that TCP_CONG_WESTWOOD related codes (example addresses such as ffffffff8106a400 and ffffffff1dad6400) were not triggered. The configuration code relationship mapping table shows the mapping relationship between kernel feature configuration and kernel code: "TCP_CONG_ADVANCED": ["ffffffff8105f500", "ffffffff82a3267e"]; "TCP_CONG_WESTWOOD":["ffffffff8106a400","ffffffff1dad6400","ffffffff812d5420"]; Combined with the coverage distribution, it can be determined that the uncovered configuration item is CONFIG_TCP_CONG_WESTWOOD, so the corresponding feature test protocol type is , used to set the configuration parameters of TCP features.

[0093] It should be noted that the above process of determining the insertion position of the feature test protocol type in the seed use case based on the coverage distribution is specifically as follows: after determining the feature test protocol type, locate the insertion position of the feature test protocol type based on the coverage distribution of the target system call in the seed use case to ensure that the test logic correctly triggers the feature code path. By analyzing the system call sequence and execution path of the seed use case, such as socket→setsockopt→close, combined with historical coverage data, the key system call position related to the feature test protocol type is identified. The key system call position is the insertion position. In a specific implementation, the resource initialization protocol (such as ) is inserted into the socket creation phase, setting the configuration parameter specification (such as ) before the setsockopt call to ensure the logic correctly triggers the feature code path.

[0094] The third step is to generate the specification parameters of the feature test specification type based on the system call test specification template, insert the specification parameters into the seed use case according to the insertion position, and obtain the fuzz test input of the target system.

[0095] Protocol parameters are relevant parameters for fuzz testing, such as TCP window size.

[0096] Specifically, according to the data types and constraints of the input parameters and return parameters of the feature-related interface functions corresponding to the target configuration in the system call test protocol template, the protocol parameters of the feature test protocol type are generated, and then the protocol parameters are inserted into the seed use case according to the insertion position to obtain the fuzzy test input of the target system.

[0097] For example, based on the system call test specification template, specification parameters that conform to the feature application logic are generated. The system call test specification template defines the data types and constraints of the function related to the feature interface, such as The system call test specification template is defined as follows: , level const[IPPROTO_TCP], opt_name const[TCP_REPAIR_WINDOW], val ptr[tcp_repair_window], len len[val]); According to the test requirements, based on the parameters contained in the above template, specific legal protocol parameters are generated, such as setting the TCP window size TCP_REPAIR_WINDOW parameter to 1024, to ensure that the test logic is consistent with the kernel feature requirements.

[0098] Finally, the generated protocol parameters are inserted into the corresponding insertion positions in the seed case to complete the reconstruction of the seed case and obtain the fuzzy test input.

[0099] It should be noted that if there are multiple target configurations, the corresponding protocol parameters and insertion positions can be obtained for each target configuration through the above process. Finally, according to the actual test requirements, one or more features that need to be tested simultaneously are selected, and all corresponding protocol parameters are inserted into the seed case according to the insertion position to obtain the fuzz test input. The fuzz test input is used to perform kernel fuzz testing on the target system.

[0100] This step is illustrated below with reference to a specific example.

[0101] The process of getting fuzz test input is as follows Figure 4 As shown, test input is generated according to the configuration code relationship mapping table and the set of configuration specification templates for the tested features, and the result of test input modeling generation is obtained. The code of the configuration code relationship mapping table part in the figure is an example of a part of the configuration code relationship mapping table, the code of the set of configuration specification templates for the tested features is the code of the seed example, and the code of the test input modeling generation part is the code of the fuzzy test input.

[0102] It is worth mentioning that the unified feature characterization modeling of the kernel configuration file and the kernel code call chain can deeply analyze the dependency of the kernel feature configuration, and combine the implementation logic of the code to build a configuration-code relationship mapping table that integrates the information of the two, effectively characterizing the relationship between the kernel feature configuration and the code. The generation of fuzzy test input based on the configuration-code relationship mapping table can closely combine the relationship between the kernel feature configuration and the fuzzy test input, thereby improving the correlation between the two.

[0103] Current kernel fuzz testing methods still have significant deficiencies in handling complex kernel feature configurations and generating high-quality test inputs, especially in the following aspects: test inputs do not match kernel feature configurations, cannot effectively cover multiple feature configuration combinations, and the generated test inputs lack pertinence. This method solves the key problems in existing solutions and improves the quality, coverage, and efficiency of test inputs.

[0104] First, this method introduces unified feature characterization technology to accurately model the complex dependencies between kernel feature configuration and code implementation. This method provides a highly integrated and unified representation method for test inputs through in-depth analysis of kernel code and feature configuration. This representation not only considers the functional logic of kernel features, but also includes its interaction mode with other configuration items. Compared with the traditional test input generation method based on system call templates, this method can better capture the real needs of kernel features, ensure that the test input is highly matched with the target feature, and avoid the defect of lack of feature association in the test input generated by the existing method.

[0105] Secondly, this method generates test inputs that reflect the dependencies between kernel features through feature dependency analysis, combined with kernel code call chains and configuration files. This method statically analyzes kernel code and configurations to accurately identify constraints and dependencies between feature configurations, so that these dependencies can be reasonably introduced into the test inputs, avoiding the problem of insufficient feature configuration coverage in current methods. Through this precise feature modeling and dependency analysis, it is possible to ensure that the generated test inputs fully cover various kernel configuration combinations, avoiding the imbalance of test coverage under multiple feature configurations.

[0106] Finally, this method uses an automated test input generation engine to automatically generate test cases that conform to the kernel feature logic through a feature semantic analysis-based technique. Unlike existing methods that require the generation of a large number of variants, this method generates test cases through efficient rules, accurately integrating kernel feature representation into the test input, and avoiding the computational overhead and resource waste caused by redundant input in traditional mutation testing. This method can improve the effectiveness and efficiency of test input without relying on the generation of a large number of variants, thereby greatly reducing computational costs.

[0107] Compared with the existing methods, this method overcomes the shortcomings of the existing technology in the following aspects: 1. Improve accuracy Through unified feature representation, this method can generate test inputs that are highly relevant to kernel features, avoiding the disconnection between test inputs and features generated in existing methods. This method not only focuses on the coverage of a single line of code, but also identifies and generates test inputs that reflect feature interactions and configuration dependencies, ensuring that the test can accurately cover kernel features and their configuration logic.

[0108] 2. Enhanced computing efficiency This method introduces feature dependency analysis, no longer relying on a large number of redundant variants, but generating test inputs through precise feature modeling. Compared with traditional fuzz testing methods, this approach significantly reduces the consumption of computing resources, avoids generating too many unnecessary test cases, and reduces the computing overhead during the testing process.

[0109] 3. Solve the problem of imbalanced coverage of multi-feature configuration combinations Since the unified representation of features can accurately represent the dependencies of different configuration items in the test input, this method can ensure that when facing multiple feature configurations, the test cases can fully cover all configuration combinations, avoiding the problem of unbalanced coverage under multiple feature configurations in existing methods. In this way, the test is more balanced and ensures that each feature configuration combination is fully tested.

[0110] 4. Precise control over test input generation Through the automated generation engine, this method can accurately control the test input generation process according to the configuration requirements of the kernel features. Compared with the blind mutation based on the system call template in the traditional method, this method automatically generates high-quality test input by analyzing the kernel configuration and functional logic, ensuring that the generated test cases not only meet the requirements of the feature configuration, but also meet the logical requirements of the kernel code, thereby improving the pertinence and quality of the test input.

[0111] 5. Comprehensive advantages This method provides an efficient and accurate test input generation method by integrating technologies such as unified feature representation, feature dependency analysis, and automated generation engine. Compared with existing methods, this method not only improves the effectiveness and pertinence of the test, but also reduces the computing cost by reducing redundant calculations and optimizing feature coverage, and solves the problem of imbalanced test combinations of multi-feature configurations. This method has higher efficiency and practicality, can provide more accurate and comprehensive support in complex kernel test scenarios, and has strong application value and promotion potential.

[0112] The following is an exemplary description of the feature-unified fuzzy test input generation device provided in the present application.

[0113] like Figure 5 As shown, the embodiment of the present application provides a fuzzy test input generation device based on characteristic unification, and the fuzzy test input generation device based on characteristic unification 500 includes: An integration module 501 is used to generate a function call graph and multiple control flow graphs of a target system, and integrate the function call graph and all control flow graphs to obtain an inter-program control flow graph; multiple nodes in the function call graph correspond one-to-one to multiple kernel source code functions of the target system, and the edges between the nodes are the call relationships between two corresponding kernel source code functions; multiple control flow graphs correspond one-to-one to multiple kernel source code functions; multiple nodes in the control flow graph correspond one-to-one to multiple basic blocks in the corresponding kernel source code functions, and the edges between the nodes are the control relationships between two corresponding basic blocks; A construction module 502 is used to construct a kernel code call chain based on the inter-program control flow graph; the kernel code call chain is used to describe the call relationship between kernel source code functions and the control relationship between basic blocks; The first generation module 503 is used to perform unified feature characterization modeling based on the kernel configuration file and the kernel code call chain of the target system, and generate a configuration code relationship mapping table; the configuration code relationship mapping table is used to describe the dependency relationship between all kernel feature configurations in the kernel configuration file and the kernel source code corresponding to each kernel feature configuration, and the kernel source code corresponds to the kernel source code function or basic block; The syntax conversion module 504 is used to extract the relevant information of the feature-related interface function according to the kernel code call chain, and perform syntax conversion based on the relevant information to generate a system call test specification template for the feature-related interface function; the relevant information is used to describe the data types and constraints of the input parameters and return parameters of the feature-related interface function, and the feature-related interface function is a kernel source code function; The second generating module 505 is used to generate a fuzzy test input for the target system based on the system call test specification template and the configuration code relationship mapping table; the fuzzy test input is a test case for testing the kernel feature configuration.

[0114] It should be noted that the information interaction, execution process, etc. between the above-mentioned devices / units are based on the same concept as the method embodiment of the present application. Their specific functions and technical effects can be found in the method embodiment part and will not be repeated here.

[0115] The technicians in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In practical applications, the above-mentioned function allocation can be completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated in a processing unit, or each unit can exist physically separately, or two or more units can be integrated in one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, which will not be repeated here.

[0116] like Figure 6 As shown, an embodiment of the present application provides a terminal device. The terminal device D10 of this embodiment includes: at least one processor D100 ( Figure 6 Only one processor is shown in the figure), a memory D101, and a computer program D102 stored in the memory D101 and executable on the at least one processor D100, wherein the processor D100 implements the steps of any of the above-mentioned method embodiments when executing the computer program D102.

[0117] Specifically, when the processor D100 executes the computer program D102, it generates a function call graph and multiple control flow graphs of the target system, integrates the function call graph and all control flow graphs, obtains an inter-program control flow graph, then builds a kernel code call chain based on the inter-program control flow graph, then performs unified feature representation modeling based on the kernel configuration file of the target system and the kernel code call chain, generates a configuration code relationship mapping table, then extracts relevant information of the feature-related interface function according to the kernel code call chain, performs syntax conversion based on the relevant information, generates a system call test specification template for the feature-related interface function, and finally generates a fuzzy test input for the target system based on the system call test specification template and the configuration code relationship mapping table. Among them, the unified feature representation modeling of the kernel configuration file and the kernel code call chain can deeply analyze the dependency relationship of the kernel feature configuration, and builds a configuration code relationship mapping table that integrates the information of the two in combination with the implementation logic of the code, effectively represents the relationship between the kernel feature configuration and the code, and generates the fuzzy test input based on the configuration code relationship mapping table, which can closely combine the relationship between the kernel feature configuration and the fuzzy test input and improve the correlation between the two.

[0118] The processor D100 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor, etc.

[0119] In some embodiments, the memory D101 may be an internal storage unit of the terminal device D10, such as a hard disk or memory of the terminal device D10. In other embodiments, the memory D101 may also be an external storage device of the terminal device D10, such as a plug-in hard disk, a smart memory card (SMC, SmartMedia Card), a secure digital (SD, Secure Digital) card, a flash card (Flash Card), etc. equipped on the terminal device D10. Further, the memory D101 may also include both an internal storage unit of the terminal device D10 and an external storage device. The memory D101 is used to store an operating system, an application program, a boot loader (BootLoader), data, and other programs, such as the program code of the computer program, etc. The memory D101 may also be used to temporarily store data that has been output or is to be output.

[0120] An embodiment of the present application further provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in the above-mentioned method embodiments can be implemented.

[0121] An embodiment of the present application provides a computer program product. When the computer program product runs on a terminal device, the terminal device can implement the steps in the above-mentioned method embodiments when executing the computer program product.

[0122] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application implements all or part of the processes in the above-mentioned embodiment method, which can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a computer-readable storage medium. When the computer program is executed by the processor, the steps of the above-mentioned various method embodiments can be implemented. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may at least include: any entity or device, recording medium, computer memory, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), electrical carrier signal, telecommunication signal and software distribution medium that can carry the computer program code to the fuzzy test input generation method device / terminal device based on unified characteristics. For example, a USB flash drive, a mobile hard disk, a disk or an optical disk.

[0123] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0124] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0125] The above is a preferred embodiment of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles described in the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.< / linux>

Claims

1. A method for generating fuzzy test input based on feature unification, characterized in that: include: Generate a function call graph and multiple control flow graphs of the target system, and integrate the function call graph and all control flow graphs to obtain an inter-program control flow graph; The multiple nodes in the function call graph correspond one-to-one to the multiple kernel source code functions of the target system, the edges between the nodes are the call relationships between the two corresponding kernel source code functions, the multiple control flow graphs correspond one-to-one to the multiple kernel source code functions, the multiple nodes in the control flow graph correspond one-to-one to the multiple basic blocks in the corresponding kernel source code functions, and the edges between the nodes are the control relationships between the two corresponding basic blocks; Constructing a kernel code call chain based on the inter-program control flow graph; The kernel code call chain is used to describe the calling relationship between kernel source code functions and the control relationship between basic blocks; Based on the kernel configuration file of the target system and the kernel code call chain, a unified characteristic representation modeling is performed to generate a configuration code relationship mapping table; the configuration code relationship mapping table is used to describe the dependency relationship between all kernel characteristic configurations in the kernel configuration file and the kernel source code corresponding to each kernel characteristic configuration, and the kernel source code corresponds to a kernel source code function or basic block; Extracting relevant information of the feature-related interface function according to the kernel code call chain, and performing syntax conversion based on the relevant information to generate a system call test specification template for the feature-related interface function; the relevant information is used to describe the data types and constraints of the input parameters and return parameters of the feature-related interface function, and the feature-related interface function is a kernel source code function; A fuzzy test input for the target system is generated based on the system call test specification template and the configuration code relationship mapping table; the fuzzy test input is a test case for testing kernel feature configuration.

2. The fuzzy test input generation method according to claim 1, characterized in that: The unified characterization modeling based on the kernel configuration file of the target system and the kernel code call chain to generate a configuration code relationship mapping table includes: According to the kernel configuration file, hierarchically identify all kernel feature configurations of the target system, dependencies between all kernel feature configurations, and kernel source code corresponding to each kernel feature configuration; A configuration-code relationship mapping table is generated based on the dependencies among all kernel source codes, all kernel feature configurations, and the kernel code call chain.

3. The fuzzy test input generation method according to claim 1, characterized in that: The extracting relevant information of the feature-related interface function according to the kernel code call chain includes: The calling path of the characteristic-related interface function of the target system in the kernel code calling chain is traced to obtain relevant information of the characteristic-related interface function.

4. The fuzzy test input generation method according to claim 1, characterized in that: The grammatical conversion based on the relevant information to generate a system call test specification template for the feature-related interface function includes: Performing language standardization on the relevant information to obtain standard relevant information in a specific description language format that complies with kernel fuzz testing; Generate a system call test specification template for the feature-related interface function according to the specification-related information.

5. The fuzzy test input generation method according to claim 4, characterized in that: The generating the fuzzy test input of the target system based on the system call test specification template and the configuration code relationship mapping table includes: Obtaining a seed case for performing kernel fuzz testing on the target system; Analyze the coverage distribution of the seed use case in the kernel fuzz test, and determine the feature test specification type that needs to be inserted based on the coverage distribution and the configuration code relationship mapping table, and determine the insertion position of the feature test specification type in the seed use case according to the coverage distribution; the coverage distribution is used to describe the code covered by the seed use case; Generate the specification parameters of the characteristic test specification type based on the system call test specification template, insert the specification parameters into the seed use case according to the insertion position, and obtain the fuzzy test input of the target system.

6. The fuzzy test input generation method according to claim 5, characterized in that: The determining the type of characteristic test specification to be inserted based on the coverage distribution and configuration code relationship mapping table includes: For the kernel feature configuration in the configuration code relationship mapping table, if the code of the feature-related interface function corresponding to the kernel feature configuration is not included in the coverage distribution, the kernel feature configuration is used as the target configuration to obtain a feature test specification type for indicating testing of the target configuration.

7. The fuzzy test input generation method according to claim 6, characterized in that: The generating the specification parameters of the characteristic test specification type based on the system call test specification template includes: The specification parameters of the characteristic test specification type are generated according to the data types and constraints of the input parameters and return parameters of the characteristic-related interface function corresponding to the target configuration in the system call test specification template.

8. A fuzzy test input generation device based on characteristic unification, characterized in that: include: An integration module, used for generating a function call graph and multiple control flow graphs of a target system, and integrating the function call graph and all control flow graphs to obtain an inter-program control flow graph; The multiple nodes in the function call graph correspond one-to-one to the multiple kernel source code functions of the target system, the edges between the nodes are the call relationships between the two corresponding kernel source code functions, the multiple control flow graphs correspond one-to-one to the multiple kernel source code functions, the multiple nodes in the control flow graph correspond one-to-one to the multiple basic blocks in the corresponding kernel source code functions, and the edges between the nodes are the control relationships between the two corresponding basic blocks; A construction module, used for constructing a kernel code call chain based on the inter-program control flow graph; The kernel code call chain is used to describe the calling relationship between kernel source code functions and the control relationship between basic blocks; A first generation module is used to perform unified characteristic representation modeling based on the kernel configuration file of the target system and the kernel code call chain, and generate a configuration code relationship mapping table; the configuration code relationship mapping table is used to describe the dependency relationship between all kernel feature configurations in the kernel configuration file and the kernel source code corresponding to each kernel feature configuration, and the kernel source code corresponds to a kernel source code function or a basic block; A syntax conversion module is used to extract relevant information of a feature-related interface function according to the kernel code call chain, and perform syntax conversion based on the relevant information to generate a system call test specification template for the feature-related interface function; the relevant information is used to describe the data types and constraints of input parameters and return parameters of the feature-related interface function, and the feature-related interface function is a kernel source code function; The second generation module is used to generate a fuzzy test input for the target system based on the system call test specification template and the configuration code relationship mapping table; the fuzzy test input is a test case for testing the kernel feature configuration.

9. A terminal device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the method for generating fuzzy test input based on feature unification as described in any one of claims 1 to 7 is implemented.

10. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the method for generating fuzzy test input based on feature unification as described in any one of claims 1 to 7 is implemented.

Images