A Fuzzing Test Input Generation Method and Related Devices Based on Feature Unification

Abstract

The present application relates to the technical field of kernel fuzz testing, and provides a method for generating fuzz testing inputs based on unified features and related devices. The method includes: 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-procedural control flow graph; constructing a kernel code call chain based on the inter-procedural control flow graph; performing unified feature 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; extracting relevant information of feature-related interface functions 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 feature-related interface functions; generating fuzz testing inputs for the target system based on the system call test specification template and the configuration code relationship mapping table. The method of the present application can improve the correlation between kernel feature configuration and fuzz testing inputs.

Description

Technical Field

[0001] This application relates to the technical field of kernel fuzz testing, and particularly to a method for generating fuzz test inputs based on unified features and related devices. Background Art

[0002] The customized features of the open-source community kernel are crucial for the stable development of the open-source community and community participating manufacturers, and their quality and security must be strongly guaranteed. With the continuous addition of new kernel customization features, new kernel defects are also increasing. There are still many challenges in the kernel quality assurance of current open-source operating system projects, especially the lack of technical capabilities for detecting kernel defects in kernel customization features.

[0003] Kernel fuzz testing is an automated operating system kernel vulnerability detection technology. The quality of fuzz test inputs has a great impact on test execution. Generating targeted test inputs that meet the functional logic of kernel features can greatly improve the test effect.

[0004] 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 configurations and code, failing to effectively combine use case descriptions with feature characterizations, unable to construct test specification templates that meet the application logic of kernel features, and lacking the ability to model targeted test inputs for kernel feature characteristics. The customized features of the open-source operating system kernel involve configuration dependencies, functional logics, and configuration combinations and interaction logics in multiple dimensions. These features are highly coupled during implementation, and there may be significant 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 relationships between kernel functions, configurations, and application scenarios, resulting in a poor correlation between fuzz test inputs and kernel features. Summary of the Invention

[0005] This application provides a method for generating fuzz test inputs based on unified features and related devices, which can solve the problem of poor correlation between fuzz test inputs and kernel features.

[0006] In a first aspect, an embodiment of this application provides a method for generating fuzz test inputs based on unified features. The fuzz test input generation method includes:

[0007] Generate the 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 the inter-procedural control flow graph; multiple nodes in the function call graph correspond one-to-one with multiple kernel source code functions of the target system, and the edges between nodes are the call relationships between the corresponding two kernel source code functions. The multiple control flow graphs correspond one-to-one with multiple kernel source code functions. Multiple nodes in the control flow graph correspond one-to-one with multiple basic blocks in the corresponding kernel source code function, and the edges between nodes are the control relationships between the corresponding two basic blocks;

[0008] Construct a kernel code call chain based on the inter-procedural control flow graph; the kernel code call chain is used to describe the call relationships between kernel source code functions and the control relationships between basic blocks;

[0009] Perform feature 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; the configuration code relationship mapping table is used to describe the dependency relationships between all kernel feature configurations in the kernel configuration file and the kernel source code corresponding to each kernel feature configuration. The kernel source code corresponds to the kernel source code function or basic block;

[0010] Extract the relevant information of the feature-related interface functions 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 functions; the relevant information is used to describe the data types and constraint conditions of the input parameters and return parameters of the feature-related interface functions. The feature-related interface functions are kernel source code functions;

[0011] Generate fuzz testing inputs for the target system based on the system call test specification template and the configuration code relationship mapping table; the fuzz testing inputs are test cases used to test the kernel feature configurations.

[0012] Optionally, perform feature 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, including:

[0013] Layer by layer identify all kernel feature configurations of the target system, the dependency relationships between all kernel feature configurations, and the kernel source code corresponding to each kernel feature configuration according to the kernel configuration file;

[0014] Generate a configuration code relationship mapping table according to all kernel source codes, the dependency relationships between all kernel feature configurations, and the kernel code call chain.

[0015] Optionally, extract the relevant information of the feature-related interface functions according to the kernel code call chain, including:

[0016] Trace the call path of the interface functions related to the characteristics of the target system in the kernel code call chain to obtain the relevant information of the interface functions related to the characteristics.

[0017] Optionally, perform syntax conversion based on the relevant information to generate a system call test specification template for the interface functions related to the characteristics, including:

[0018] Normalize the relevant information in terms of language to obtain the specification-related information in a specific description language format that conforms to kernel fuzz testing.

[0019] Generate a system call test specification template for the interface functions related to the characteristics according to the specification-related information.

[0020] Optionally, generate fuzz testing inputs for the target system based on the system call test specification template and the configuration code relationship mapping table, including:

[0021] Obtain the seed case for kernel fuzz testing of the target system.

[0022] Analyze the coverage distribution of the seed case in kernel fuzz testing, determine the type of feature test specification to be inserted based on the coverage distribution and the configuration code relationship mapping table, and determine the insertion position of the type of feature test specification in the seed case; the coverage distribution is used to describe the code covered by the seed case.

[0023] Generate the specification parameters of the type of feature test specification based on the system call test specification template, and insert the specification parameters into the seed case according to the insertion position to obtain the fuzz testing input for the target system.

[0024] Optionally, determine the type of feature test specification to be inserted based on the coverage distribution and the configuration code relationship mapping table, including:

[0025] For the kernel feature configuration in the configuration code relationship mapping table, if the code of the interface function related to the kernel feature configuration is not included in the coverage distribution, then use the kernel feature configuration as the target configuration to obtain the type of feature test specification for indicating the test of the target configuration.

[0026] Optionally, generate the specification parameters of the type of feature test specification based on the system call test specification template, including:

[0027] Generate the specification parameters of the type of feature test specification according to the data types and constraint conditions of the input parameters and return parameters of the interface function related to the target configuration in the system call test specification template.

[0028] In a second aspect, an embodiment of the present application provides a fuzz testing input generation device based on feature unification, including:

[0029] An integration module 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-procedural control flow graph. Multiple nodes in the function call graph correspond one-to-one with 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. The multiple control flow graphs correspond one-to-one with multiple kernel source code functions. Multiple nodes in the control flow graph correspond one-to-one with multiple basic blocks in the corresponding kernel source code function, and the edges between the nodes are the control relationships between the corresponding two basic blocks.

[0030] A construction module is used to construct a kernel code call chain based on the inter-procedural control flow graph. The kernel code call chain is used to describe the call relationships between kernel source code functions and the control relationships between basic blocks.

[0031] A first generation module is used to perform feature unified characterization 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 relationships between all kernel feature configurations in the kernel configuration file and the kernel source code corresponding to each kernel feature configuration. The kernel source code corresponds to a kernel source code function or a basic block.

[0032] A syntax conversion module is used to extract relevant information of feature-related interface functions 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 feature-related interface functions. The relevant information is used to describe the data types and constraint conditions of the input parameters and return parameters of the feature-related interface functions. The feature-related interface functions are kernel source code functions.

[0033] A second generation module is used to generate fuzz testing inputs for the target system based on the system call test specification template and the configuration code relationship mapping table. The fuzz testing inputs are test cases used to test kernel feature configurations.

[0034] 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. When the processor executes the computer program, the above-mentioned method for generating fuzz testing inputs based on feature unification is implemented.

[0035] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, the above-mentioned method for generating fuzz testing inputs based on feature unification is implemented.

[0036] The above solution of the present application has the following beneficial effects:

[0037] In the embodiments of the present application, by generating a function call graph and multiple control flow graphs of the target system, integrating the function call graph and all control flow graphs to obtain an inter-procedural control flow graph, then constructing a kernel code call chain based on the inter-procedural control flow graph, and then performing a unified characterization modeling of features based on the kernel configuration file of the target system and the kernel code call chain to generate a configuration code relationship mapping table, then extracting relevant information of the feature-related interface functions based on 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 functions, and finally generating a fuzz testing input for the target system based on the system call test specification template and the configuration code relationship mapping table. Among them, performing a unified characterization modeling of features on the kernel configuration file and the kernel code call chain 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 both, effectively characterizing the relationship between the kernel feature configuration and the code. Generating fuzz testing inputs based on the configuration code relationship mapping table can closely combine the relationship between the kernel feature configuration and the fuzz testing inputs, improving the correlation between the two.

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

[0039] To more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0040] Figure 1 It is a flowchart of a method for generating fuzz testing inputs based on unified features provided by an embodiment of the present application;

[0041] Figure 2 It is a flowchart of generating a configuration code relationship mapping table provided by an embodiment of the present application;

[0042] Figure 3 It is a flowchart of generating a system call test specification template provided by an embodiment of the present application;

[0043] Figure 4 It is a flowchart of generating fuzz testing inputs provided by an embodiment of the present application;

[0044] Figure 5 It is a schematic structural diagram of a device for generating fuzz testing inputs based on unified features provided by an embodiment of the present application;

[0045] Figure 6Schematic structural diagram of a terminal device provided by an embodiment of the present application. Detailed implementation manners

[0046] In the following description, for the purpose of illustration rather than limitation, specific details such as specific system architectures and technologies are presented in order to thoroughly understand the embodiments of the present application. However, those skilled in the art should clearly understand that the present application can 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 avoid unnecessary details from interfering with the description of the present application.

[0047] It should be understood that when used in the specification and appended claims of the present application, the term "comprising" indicates the presence of the 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 their combinations.

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

[0049] As used in the specification and appended claims of the present application, the term "if" can be interpreted as "when" or "once" or "in response to determining" or "in response to detecting" according to the context. Similarly, the phrase "if determined" or "if detecting [the described condition or event]" can be interpreted as meaning "once determined" or "in response to determining" or "once detecting [the described condition or event]" or "in response to detecting [the described condition or event]" according to the context.

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

[0051] The reference to "an embodiment" or "some embodiments" etc. described in the specification of the present application means that a specific feature, structure, or characteristic described in connection with the embodiment is included in one or more embodiments of the present application. Thus, the statements "in an embodiment", "in some embodiments", "in other some embodiments", "in still other embodiments", etc. that appear in different places in this specification do not necessarily all refer to the same embodiment, but mean "one or more but not all embodiments", unless otherwise specifically emphasized in other ways. The terms "comprising", "including", "having", and their variants all mean "including but not limited to", unless otherwise specifically emphasized in other ways.

[0052] Aiming at the problem of poor correlation between existing fuzzing inputs and kernel features, an embodiment of the present application provides a method for generating fuzzing inputs based on feature unification. This method for generating fuzzing inputs generates a function call graph and multiple control flow graphs of the target system, integrates the function call graph and all control flow graphs to obtain an inter-procedural control flow graph, then constructs a kernel code call chain based on the inter-procedural control flow graph, and then performs feature-unified characterization modeling based on the kernel configuration file and the kernel code call chain of the target system to generate a configuration code relationship mapping table. Then, relevant information of feature-related interface functions is extracted based on the kernel code call chain, and syntax conversion is performed based on the relevant information to generate a system call test specification template for feature-related interface functions. Finally, fuzzing inputs for the target system are generated based on the system call test specification template and the configuration code relationship mapping table. Among them, performing feature-unified characterization modeling on the kernel configuration file and the kernel code call chain can deeply analyze the dependency relationship of kernel feature configurations, and combine the implementation logic of the code to construct a configuration code relationship mapping table that integrates the information of both, effectively representing the relationship between kernel feature configurations and code. Generating fuzzing inputs based on the configuration code relationship mapping table can closely combine the relationship between kernel feature configurations and fuzzing inputs, improving the correlation between the two.

[0053] The following explains the relevant technical terms of the present application.

[0054] Kernel fuzzing, an automated operating system kernel vulnerability detection technology, injects a large number of unexpected system call sequence inputs into the operating system kernel to simulate different usage scenarios and system boundary conditions, in order to discover potential code anomalies and potential defects, and is often applied to software security research.

[0055] Feature unified characterization is to analyze the operating system kernel code and configuration files through program analysis techniques to construct a structured representation of the dependency relationship between kernel feature configurations and code implementations. Its purpose is to eliminate the "semantic gap" between kernel feature configurations and actual code implementations, so that test inputs can accurately reflect the functional requirements and configuration logic of kernel features, thus providing support for efficient fuzzing.

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

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

[0058] The Call Graph (CG) is a graph structure that represents the call relationships between functions in a program. Each node in the graph represents a function in the program, and the edges represent that one function calls another function. Through the Call Graph, developers can intuitively see the call chains between functions in the program, which helps analyze the structure and logic of the program. CG is commonly used in static analysis, performance optimization, and vulnerability detection.

[0059] The Control Flow Graph (CFG) is a graph structure that represents the control flow relationships 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 edges represent the execution paths of the control flow from one basic block to another. CFG is used to reveal control structures such as branches and loops in the program and is widely applied in scenarios such as code optimization, path analysis, and vulnerability detection.

[0060] The Interprocedural Control Flow Graph (ICFG) is an extension of the Control Flow Graph (CFG). It takes into account both the control flow within functions and the control flow relationships between different functions. ICFG combines the Call Graph (CG) and the Control Flow Graph (CFG) to show the control flow paths 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.

[0061] 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.

[0062] Kernel feature configurations are configuration options used to control the features of the system. Features refer to various functions or capabilities supported by the operating system, such as hardware support, kernel modules, scheduling policies, memory management policies, etc.

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

[0064] A test case is a description of the testing tasks for software or a system, which embodies testing schemes, methods, techniques, and strategies. Its content includes test objectives, test environments, input data, test steps, expected results, test scripts, etc., and finally forms a document.

[0065] Next, an exemplary description will be given of the unified feature-based fuzz testing input generation method provided in this application.

[0066] Such as Figure 1As shown in the figure, the method for generating fuzzy test inputs based on unified characteristics provided by this application includes the following steps:

[0067] 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-procedural control flow graph.

[0068] Multiple nodes in the above function call graph correspond one-to-one with multiple kernel source code functions of the target system. 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 with multiple kernel source code functions. Multiple nodes in the control flow graph correspond one-to-one with multiple basic blocks in the corresponding kernel source code function. The edges between the nodes are the control relationships between the corresponding two 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.

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

[0070] Step 12: Construct a kernel code call chain based on the inter-procedural control flow graph.

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

[0072] Specifically, according to the call relationships between all kernel source code functions described by the inter-procedural control flow graph (ICFG), a part of the kernel code call chain is generated. For example, function A calls function B, and function B calls function C. Then, based on the call relationships 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. For example, basic block 1 in function A calls basic block 2, and basic block 2 calls basic block 3. Finally, these two parts are combined into a complete kernel code call chain.

[0073] Step 13: Perform unified characteristic representation 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.

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

[0075] In some embodiments of the present application, the steps of characterizing and modeling the kernel configuration file and the kernel code call chain of the target system to generate a configuration code relationship mapping table include:

[0076] First step, 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 according to the hierarchical structure of the kernel configuration file.

[0077] It should be noted that the kernel configuration file can be a Kconfig file.

[0078] Specifically, the specific process of this step includes:

[0079] 1. Parse the Kconfig file

[0080] First, extract all configuration options (i.e., kernel feature configurations) and their dependencies from the kernel's Kconfig file. The Kconfig file is the core of the Linux kernel configuration system, containing the definition of each configuration option, dependencies (such as depends on and select), and their description information.

[0081] The specific approach is as follows:

[0082] Traverse all config entries in the Kconfig file to extract the name of the configuration option, the dependency conditions (such as the depends on statement), and the selected items (such as the select statement).

[0083] 2. Construct a directed graph of dependencies for the configuration options

[0084] After obtaining all configuration options and their dependencies, construct these relationships into a directed graph of dependencies.

[0085] Nodes: Each node in the directed graph of dependencies represents a configuration option (e.g., CONFIG_A).

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

[0087] Storage method: The directed graph of dependencies can be stored using the data structure of an adjacency list or an adjacency matrix.

[0088] Through this graph structure, the dependencies between all configuration options can be intuitively represented, and subsequent layer-by-layer parsing can be performed based on this graph.

[0089] 3. Achieve hierarchical identification through topological sorting

[0090] To identify the hierarchical relationships of configuration options, a topological sort can be performed on the dependency directed graph to organize the configuration options layer by layer according to the dependency levels. The specific steps are as follows:

[0091] Initialize layer 0: First, find all the nodes in the graph that have no dependencies (i.e., nodes with an in-degree of 0). These nodes belong to layer 0 because they do not depend on any other configuration options.

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

[0093] Identify the nodes in the next layer: Among the remaining nodes, continue to find the nodes with an in-degree of 0. These nodes belong to layer 1.

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

[0095] Finally, the nodes in the dependency directed graph will be organized in layers. The higher the layer, the more complex the configuration options it depends on.

[0096] Example:

[0097] For the following dependencies:

[0098] CONFIG_C depends on CONFIG_B

[0099] CONFIG_B depends on CONFIG_A

[0100] CONFIG_D depends on CONFIG_A

[0101] Hierarchical result:

[0102] Layer 0: CONFIG_A (no dependencies)

[0103] Layer 1: CONFIG_B, CONFIG_D (depend on CONFIG_A)

[0104] Layer 2: CONFIG_C (depend on CONFIG_B)

[0105] 4. Associate configuration options with the kernel source code

[0106] 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:

[0107] Traverse the Makefile files under the kernel source code directory to find the compilation instructions related to the configuration options, such as:

[0108] ;

[0109] ;

[0110] In this example, CONFIG_A corresponds to module_a.o in the kernel source code, and CONFIG_B corresponds to module_b.o in the kernel source code.

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

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

[0113] 5. Generate a hierarchical dependency mapping table

[0114] Finally, based on the previous parsing results, generate a hierarchical dependency mapping table, which details:

[0115] Configuration option: The name of each configuration option.

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

[0117] Dependency relationship: Other configuration options on which the configuration option depends.

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

[0119] In the second step, 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.

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

[0121] The following uses a specific example to exemplarily illustrate the above steps of generating the configuration code relationship mapping table.

[0122] Such as Figure 2As shown in the figure, on the one hand, an inter-procedural control flow graph ICFG is constructed based on the kernel source code files. The ICFG includes a CG and multiple CFGs. In the 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 numbers of the call paths. N / A represents a function with no further call relationship. CFG(a) and CFG(b) respectively represent the CFGs corresponding to the kernel source code function a and the kernel source code function b. In the CFG, a and c represent the numbers of basic blocks. Then, a kernel code call chain is constructed, and the arrows represent call relationships or control relationships. On the other hand, the Makefile file (which specifies which source code files belong to which modules and includes compiler options, link options, etc.) is configured and mapped based on the kernel configuration file. Then, the dependency relationship is obtained through configuration dependency analysis. The dependency relationship and the kernel code call chain are modeled for characteristic code representation to obtain a configuration-code relationship mapping table. Figure 2 in , is a mapping expression between configuration options and target files, which 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 the configuration options represent dependency relationships. The code "#inculde <linux spinlock>"Indicates the kernel synchronization mechanism files that certain configuration options may introduce, and "rcu_pending rcu_momentary_dyntick" indicates the kernel operations or status flags that certain configuration options may be associated with. The multiple lines of code corresponding to the configuration-code relationship mapping table in the figure are examples of a part of the configuration-code relationship mapping table, which are used to describe the association between configuration options and kernel code implementations.

[0123] Step 14: Extract the relevant information of the feature-related interface functions 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 functions.

[0124] The above relevant information is used to describe the data types and constraint conditions of the input parameters and return parameters of the feature-related interface functions, and the feature-related interface functions are kernel source code functions.

[0125] In some embodiments of the present application, the steps of extracting the relevant information of the feature-related interface functions 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 functions include:

[0126] The first step: Trace the call path of the feature-related interface functions of the target system in the kernel code call chain to obtain the relevant information of the feature-related interface functions.

[0127] Exemplarily, through semantic static analysis, trace the call path of the feature-related interface functions in the kernel code call chain to obtain the data types and constraint conditions of the input parameters and return parameters of the feature-related interface functions.

[0128] It should be noted that the data type is used to define the legal type range of the input and output parameters, such as int, struct tcp_info, etc. The constraint conditions limit the legal value range of the data, such as the input parameter cannot be NULL, and the return value must be greater than 0, etc.

[0129] The second step: Normalize the relevant information to obtain the specification-related information in the format of a specific description language that conforms to kernel fuzz testing.

[0130] It should be noted that the extracted data types and constraint conditions are mapped to the syntax of the fuzz testing 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 the parameter range 0 < x < 1000) of the feature-related interface functions.

[0131] The third step: Generate a system call test specification template for the feature-related interface functions according to the specification-related information.

[0132] Specifically, construct the data plane and the control plane according to the specification-related information, and integrate the data plane and the control plane to obtain the system call test specification template.

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

[0134] The following uses a specific example to illustrate this step exemplarily.

[0135] The process of generating the system call test specification template is as Figure 3 shown. Trace the function call path 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 constraint conditions), and then perform syntax conversion to obtain the test specification integrating feature configurations (i.e., the system call test specification template). Figure 3 The code in the box corresponding to the configuration code call chain in the figure is the code of the kernel source code function, the arrow is the function call relationship, the code in the structure type and constraints part is the code describing data types and constraint conditions, and the code in the test specification part is the code of the system call test specification template.

[0136] Step 15, generate fuzz testing inputs for the target system based on the system call test specification template and the configuration code relationship mapping table.

[0137] The above fuzz testing inputs are test cases for testing kernel feature configurations.

[0138] In some embodiments of the present application, the step of generating fuzz testing inputs for the target system based on the system call test specification template and the configuration code relationship mapping table includes:

[0139] The first step, obtain a seed case for kernel fuzz testing of the target system.

[0140] The second step, analyze the coverage distribution of the seed case in kernel fuzz testing, and determine the type of feature test specification 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 case according to the coverage distribution.

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

[0142] Specifically, the specific process of determining the type of feature test specification 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, the kernel feature configuration is used as the target configuration to obtain the type of feature test specification for indicating the test of the target configuration.

[0143] Exemplarily, coverage distribution analysis: Perform coverage analysis on historical test cases to extract which code has been covered and which has not been triggered yet. For example, code coverage analysis finds that the code related to TCP_CONG_WESTWOOD (example addresses such as ffffffff8106a400 and ffffffff1dad6400) has not been triggered. The configuration code relationship mapping table shows the mapping relationship between kernel feature configurations and kernel code:

[0144] "TCP_CONG_ADVANCED": ["ffffffff8105f500", "ffffffff82a3267e"];

[0145] "TCP_CONG_WESTWOOD": ["ffffffff8106a400", "ffffffff1dad6400", "ffffffff812d5420"];

[0146] Combined with the coverage distribution, it can be determined that the uncovered configuration item is CONFIG_TCP_CONG_WESTWOOD, so the corresponding type of feature test specification is , which is used to set the configuration parameters of the TCP feature.

[0147] It should be noted that the specific process of determining the insertion position of the type of feature test specification in the seed cases according to the coverage distribution is as follows: After determining the type of feature test specification, based on the coverage distribution of the target system call in the seed cases, locate the insertion position of the type of feature test specification to ensure that the test logic correctly triggers the feature code path. By analyzing the system call sequence and execution path of the seed cases, such as socket→setsockopt→close, combined with historical coverage data, identify the key system call positions related to this type of feature test specification, and this key system call position is the insertion position. In specific implementation, the resource initialization specification (such as ) can be inserted into the socket creation stage, and the configuration parameter setting specification (such as ) can be inserted before the setsockopt call to ensure that the logic correctly triggers the feature code path.

[0148] In the third step, generate the specification parameters of the feature test specification type based on the system call test specification template, and insert the specification parameters into the seed use cases according to the insertion positions to obtain the fuzz testing input for the target system.

[0149] The specification parameters are the relevant parameters for fuzz testing, such as the TCP window size, etc.

[0150] Specifically, according to the data types and constraint conditions of the input parameters and return parameters of the feature-related interface functions corresponding to the target configuration in the system call test specification template, generate the specification parameters of the feature test specification type, and then insert the specification parameters into the seed use cases according to the insertion positions to obtain the fuzz testing input for the target system.

[0151] Exemplarily, based on the system call test specification template, generate the specification parameters that conform to the feature application logic. The system call test specification template defines the data types and constraint conditions of the feature interface-related functions, for example The system call test specification template is defined as follows:

[0152] ,

[0153] level const[IPPROTO_TCP],

[0154] opt_name const[TCP_REPAIR_WINDOW],

[0155] val ptr[tcp_repair_window],

[0156] len len[val]);

[0157] According to the test requirements, specifically generate legal specification parameters according to the parameters included in the above template. For example, set the TCP_REPAIR_WINDOW parameter of the TCP window size to 1024 to ensure that the test logic is consistent with the kernel feature requirements.

[0158] Finally, insert the generated specification parameters into the corresponding insertion positions in the seed use cases, complete the reconstruction of the seed use cases, and obtain the fuzz testing input.

[0159] It should be noted that if there are multiple target configurations, the corresponding specification parameters and insertion positions can be obtained for each target configuration through the above process. Finally, according to the actual test requirements, select one or more features that need to be tested simultaneously, and insert all the corresponding specification parameters into the seed use cases according to the insertion positions to obtain the fuzz testing input. Use the fuzz testing input to perform kernel fuzz testing on the target system.

[0160] The following uses a specific example to exemplarily illustrate this step.

[0161] The process of obtaining fuzz test inputs is as Figure 4 shown. Test inputs are generated according to the configuration code relationship mapping table and the set of test feature configuration specification templates, and the results of test input modeling generation are obtained. The code in the part of the configuration code relationship mapping table in the figure is an example part of the configuration code relationship mapping table, the code in the part of the test feature configuration specification template set is the code of the seed example, and the code in the part of test input modeling generation is the code of the fuzz test input.

[0162] It is worth mentioning that by performing unified characterization modeling on the kernel configuration file and the kernel code call chain, the dependency relationship of kernel feature configuration can be deeply analyzed, and combined with the implementation logic of the code, a configuration code relationship mapping table integrating the information of both can be constructed, effectively characterizing the relationship between kernel feature configuration and code. Based on the configuration code relationship mapping table, the generation of fuzz test inputs can closely combine the relationship between kernel feature configuration and fuzz test inputs, improving the correlation between the two.

[0163] The current kernel fuzz testing method still has significant deficiencies in dealing with complex kernel feature configurations and generating high-quality test inputs, especially in the following aspects: the mismatch between test inputs and kernel feature configurations, the inability to effectively cover multi-feature configuration combinations, and the lack of pertinence in the generated test inputs. This method solves the key problems in the existing solutions and improves the quality, coverage, and efficiency of test inputs.

[0164] First of all, this method accurately models the complex dependency relationship between kernel feature configuration and code implementation by introducing the feature unified characterization technology. Through in-depth analysis of the kernel code and feature configuration, this method provides a highly integrated and unified characterization method for test inputs. This characterization not only considers the functional logic of kernel features but also includes their interaction patterns with other configuration items. Compared with the traditional test input generation method based on system call templates, this method can better capture the real requirements of kernel features, ensure a high degree of matching between test inputs and target features, and avoid the defect of lack of feature association in the test inputs generated by the existing methods.

[0165] Secondly, through feature dependency analysis, this method combines the kernel code call chain and configuration files to generate test inputs that can reflect the dependencies between kernel features. By statically analyzing the kernel code and configuration, this method can accurately identify the constraints and dependencies between feature configurations, and thus reasonably introduce these dependencies into the test inputs, avoiding the problem of insufficient coverage of feature configurations in the current method. Through this precise feature modeling and dependency analysis, it can ensure that the generated test inputs comprehensively cover various kernel configuration combinations, avoiding the imbalance of test coverage under multi-feature configurations.

[0166] Finally, this method adopts an automated test input generation engine. Through techniques based on feature semantic analysis, it automatically generates test cases that conform to the logic of kernel features. Different from the existing methods that require a large number of mutants to be generated, this method generates test cases through efficient rules, accurately integrating the kernel feature representations into the test inputs, and avoiding the computational overhead and resource waste caused by redundant inputs in traditional mutation testing. This method can improve the effectiveness and efficiency of test inputs without relying on the generation of a large number of mutants, thus greatly reducing the computational cost.

[0167] Compared with the existing methods, this method overcomes the disadvantages of the existing technologies in the following aspects:

[0168] 1. Improve accuracy

[0169] Through unified feature representation, this method can generate test inputs that are highly relevant to kernel features, avoiding the disconnection problem between the generated test inputs and features in the existing methods. This method not only focuses on the coverage of individual code lines, but also can identify and generate test inputs that can reflect feature interactions and configuration dependencies, ensuring that the tests can accurately cover the kernel features and their configuration logics.

[0170] 2. Enhance computational efficiency

[0171] By introducing feature dependency analysis, this method no longer relies on the generation of a large number of redundant mutants, but generates test inputs through precise feature modeling. Compared with traditional fuzz testing methods, this approach significantly reduces the consumption of computational resources, avoids generating too many unnecessary test cases, and reduces the computational overhead during the testing process.

[0172] 3. Solve the problem of unbalanced coverage of multi-feature configuration combinations

[0173] Since the unified characterization of features can accurately represent the dependencies of different configuration items in the test input, this method can ensure that when faced with multi-feature configurations, test cases can comprehensively cover all configuration combinations, avoiding the problem of coverage imbalance in multi-feature configurations in existing methods. In this way, the testing is more balanced, ensuring that each feature configuration combination is fully tested.

[0174] 4. Precise control of test input generation

[0175] Through the automated generation engine, this method can precisely control the generation process of test inputs according to the configuration requirements of kernel features. Compared with the blind mutation based on system call templates in traditional methods, this method analyzes the kernel configuration and functional logic to automatically generate high-quality test inputs, ensuring that the generated test cases not only meet the requirements of feature configurations but also conform to the logic requirements of the kernel code, thus improving the pertinence and quality of test inputs.

[0176] 5. Comprehensive advantages

[0177] By integrating technologies such as unified feature characterization, feature dependency analysis, and automated generation engine, this method provides an efficient and accurate method for generating test inputs. Compared with existing methods, this method not only improves the effectiveness and pertinence of testing but also reduces the computational cost by reducing redundant calculations and optimizing feature coverage, and solves the problem of unbalanced testing of multi-feature configuration combinations. This method has higher efficiency and practicality, can provide more accurate and comprehensive support in complex kernel testing scenarios, and has strong application value and promotion potential.

[0178] Next, an exemplary description is provided for the fuzz testing input generation device based on unified features provided in this application.

[0179] As Figure 5 shown, an embodiment of this application provides a fuzz testing input generation device based on unified features. The fuzz testing input generation device 500 based on unified features includes:

[0180] An integration module 501, configured 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-procedural control flow graph; multiple nodes in the function call graph correspond one-to-one to multiple kernel source code functions of the target system, 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 function, and the edges between the nodes are the control relationships between the corresponding two basic blocks;

[0181] A construction module 502 for constructing a kernel code call chain based on an 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;

[0182] A first generation module 503 for performing characteristic unified characterization modeling based on a kernel configuration file of a target system and the kernel code call chain 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, where the kernel source code corresponds to a kernel source code function or a basic block;

[0183] A syntax conversion module 504 for extracting relevant information of characteristic - related interface functions 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 characteristic - related interface functions; the relevant information is used to describe the data types and constraint conditions of the input parameters and return parameters of the characteristic - related interface functions, and the characteristic - related interface functions are kernel source code functions;

[0184] A second generation module 505 for generating fuzz testing inputs for the target system based on the system call test specification template and the configuration - code relationship mapping table; the fuzz testing inputs are test cases for testing kernel characteristic configurations.

[0185] It should be noted that for the information interaction, execution process, etc. between the above - mentioned devices / units, since they are based on the same concept as the method embodiment of the present application, for their specific functions and the technical effects brought, reference can be specifically made to the method embodiment part, and details are not described herein again.

[0186] Those skilled in the art can clearly understand that for the sake of convenience and brevity of description, only the above - mentioned division of each functional unit and module is used as an example. In actual applications, the above - mentioned functions can be allocated to different functional units and modules according to needs, that is, the internal structure of the device is divided into different functional units or modules to complete all or part of the functions described above. Each functional unit and module in the embodiment can be integrated into a processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above - mentioned integrated units can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of each functional unit and module are only for the convenience of mutual distinction and do not limit the protection scope of the present application. The specific working process of the units and modules in the above - mentioned system can refer to the corresponding process in the foregoing method embodiment, and details are not described herein again.

[0187] Such as Figure 6 As shown in the figure, 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), a memory D101, and a computer program D102 stored in the memory D101 and executable on the at least one processor D100. When the processor D100 executes the computer program D102, the steps in any of the above method embodiments are implemented.

[0188] Specifically, when the processor D100 executes the computer program D102, by generating a function call graph and multiple control flow graphs of the target system, integrating the function call graph and all control flow graphs to obtain an inter-procedural control flow graph, then constructing a kernel code call chain based on the inter-procedural control flow graph, then performing a unified characterization modeling of the kernel configuration file of the target system and the kernel code call chain to generate a configuration code relationship mapping table, then extracting relevant information of the feature-related interface functions based on the kernel code call chain, and performing a syntax conversion based on the relevant information to generate a system call test specification template for the feature-related interface functions, and finally generating a fuzz test input for the target system based on the system call test specification template and the configuration code relationship mapping table. Among them, performing a unified characterization modeling of the kernel configuration file and the kernel code call chain 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 both, effectively characterizing the relationship between the kernel feature configuration and the code. Generating fuzz test inputs based on the configuration code relationship mapping table can closely combine the relationship between the kernel feature configuration and the fuzz test inputs, improving the correlation between the two.

[0189] The so-called processor D100 may be a central processing unit (CPU, Central Processing Unit), and this processor D100 may also be other general-purpose processors, digital signal processors (DSP, Digital Signal Processor), application specific integrated circuits (ASIC, Application Specific Integrated Circuit), field-programmable gate arrays (FPGA, Field-Programmable Gate Array), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.

[0190] 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 some 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 media card (SMC), a secure digital (SD) card, a flash card, etc., equipped on the terminal device D10. Further, the memory D101 may also include both the internal storage unit and the external storage device of the terminal device D10. The memory D101 is used to store an operating system, application programs, a boot loader (BootLoader), data, and other programs, such as program codes of the computer program. The memory D101 may also be used to temporarily store data that has been output or is to be output.

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

[0192] An embodiment of the present application provides a computer program product, and when the computer program product runs on a terminal device, the terminal device is enabled to implement the steps in the above method embodiments.

[0193] 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 such an understanding, to implement all or part of the processes in the above method embodiments of the present application, a computer program can be used to instruct relevant hardware to complete, and the computer program can be stored in a computer-readable storage medium. When the computer program is executed by a processor, the steps in the above method embodiments can be implemented. Among them, the computer program includes computer program code, and the computer program code can be in the form of source code, object code, an executable file, or some intermediate form, etc. The computer-readable medium may at least include: any entity or device capable of carrying the computer program code to the method and apparatus for generating fuzzy test inputs based on feature unification / terminal device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. For example, a USB flash drive, a mobile hard disk, a magnetic disk, or an optical disc, etc.

[0194] In the above embodiments, the descriptions of the respective embodiments have their own emphases. For the parts not detailed or recorded in a certain embodiment, reference may be made to the relevant descriptions of other embodiments.

[0195] Those of ordinary skill in the art can realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware or a combination of computer software and electronic hardware. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. A professional technician can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of this application.

[0196] The above is the preferred embodiment of this application. It should be noted that for those of ordinary skill in the art of this technology, without departing from the principle described in this application, several improvements and refinements can be made, and these improvements and refinements should also be regarded as the protection scope of this 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