System kernel fuzz testing seed generation method and system based on large language model

Abstract

The present application relates to the field of data processing technology, and discloses a system kernel fuzz test seed generation method and system based on a large language model. The method comprises: extracting features of Linux kernel system calls on a host host to obtain a feature data set; analyzing the feature data set based on CFG to obtain a system call sequence diagram and extracting a state transition table; constructing a test scenario for the state transition table and verifying it with Syzkaller to obtain a valid scenario library; generating an initial seed case set for the valid scenario library and executing the test in QEMU to obtain result data; performing coverage analysis on the result data to obtain a coverage report and optimizing the generation of a target test case set. The present application improves test coverage and defect discovery capabilities.

Description

Technical Field

[0001] The present application relates to the field of data processing, and in particular to a method and system for generating system kernel fuzzy test seeds based on a large language model. Background Art

[0002] In the current field of system kernel security testing, fuzz testing is a widely used automated testing method. Traditional kernel fuzz testing mainly relies on open source tools such as Syzkaller and Trinity to discover potential kernel vulnerabilities by randomly generating or mutating system call sequences. These tools usually use a coverage-guided approach to optimize test cases and combine virtual machine technology (such as QEMU) to provide an isolated test environment. At the same time, static analysis technology is used to extract characteristic information of system calls, including parameter constraints, return value types, and exception handling logic, to assist in generating effective test cases.

[0003] However, existing kernel fuzz testing methods have some obvious shortcomings. First, traditional random generation methods have difficulty in generating semantically reasonable system call sequences, resulting in a large number of invalid or duplicate test cases. Second, existing tools lack a deep understanding of the dependencies and state transitions between system calls, making it difficult to construct complex test scenarios. In addition, the test case generation process lacks intelligent guidance, making it difficult to accurately test specific code areas, resulting in low test efficiency. Summary of the invention

[0004] This application provides a system kernel fuzz test seed generation method and system based on a large language model, which is used to solve how to use the semantic understanding ability of the large language model to realize the intelligent construction of system call sequences and improve the effectiveness and coverage of test cases. By introducing a large language model to analyze and reason about system call features, the dependencies between calls can be better understood, and more valuable test scenarios can be generated, thereby improving the effect of kernel fuzz testing.

[0005] In a first aspect, the present application provides a system kernel fuzz test seed generation method based on a large language model, the system kernel fuzz test seed generation method based on a large language model comprising: performing feature extraction processing on a Linux kernel system call on a host host to obtain a system call feature data set, the system call feature data set comprising call parameters, return value type and abnormal state;

[0006] Performing call relationship analysis processing based on a control flow graph CFG on the system call feature data set to obtain a system call sequence diagram, and performing dependency state extraction processing on the system call sequence diagram to obtain a state transition table;

[0007] Performing a test scenario construction process on the state transition table to obtain a test scenario set, and performing an executable verification process on the test scenario set using a Syzkaller tool to obtain a valid scenario library;

[0008] Perform seed use case generation processing on the effective scenario library to generate an initial seed use case set of the system call sequence, and perform execution test processing on the initial seed use case set through a guest machine simulated by QEMU to obtain execution result data;

[0009] The execution result data is subjected to coverage analysis to obtain a coverage report, and the seed test case is optimized according to the coverage report to obtain a target test case set.

[0010] In a second aspect, the present application provides a system kernel fuzzy test seed generation system based on a large language model, and the system kernel fuzzy test seed generation system based on a large language model includes:

[0011] The acquisition module is used to perform feature extraction processing on the Linux kernel system call on the Host host to obtain a system call feature data set, wherein the system call feature data set includes call parameters, return value type and abnormal status;

[0012] An analysis module is used to perform call relationship analysis processing on the system call feature data set based on a control flow graph CFG to obtain a system call sequence diagram, and perform dependency state extraction processing on the system call sequence diagram to obtain a state transition table;

[0013] A construction module is used to perform a test scenario construction process on the state transition table to obtain a test scenario set, and use a Syzkaller tool to perform an executable verification process on the test scenario set to obtain a valid scenario library;

[0014] A generation module is used to perform seed use case generation processing on the effective scenario library, generate an initial seed use case set of the system call sequence, and perform execution test processing on the initial seed use case set through a guest machine simulated by QEMU to obtain execution result data;

[0015] The optimization module is used to perform coverage analysis on the execution result data to obtain a coverage report, and optimize the seed test case according to the coverage report to obtain a target test case set.

[0016] In the technical solution provided by the present application, the Linux kernel system call features are extracted on the Host host, and the system call feature data set formed contains complete call parameters, return value types and abnormal state information, which provides a comprehensive feature basis for subsequent tests and avoids the test blind spots caused by incomplete feature extraction in traditional methods. The system call sequence diagram is obtained by analyzing the call relationship based on the control flow graph CFG, and the dependent state is extracted to obtain the state transition table, which accurately grasps the dependency relationship and state transition law between system calls and improves the rationality of the test scenario. On this basis, the test scenario set is constructed using a large language model, and the executable verification is combined with the Syzkaller tool to obtain an effective scenario library, which gives full play to the semantic understanding ability of the large language model, and the generated test scenario is more in line with the actual use scenario. The seed case is generated for the effective scenario library, and the execution test is performed through the QEMU simulation environment to ensure the executability and effectiveness of the test case, and avoid the waste of resources caused by invalid testing. Finally, the target test case set is obtained through coverage analysis and optimization processing, which realizes the continuous optimization of the test case and the continuous improvement of the coverage rate. The overall solution realizes the intelligence and automation of system call testing by combining technologies such as large language models, control flow analysis, and virtualization testing, thereby improving testing efficiency and test coverage. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0018] Figure 1 A schematic diagram of an embodiment of a method for generating system kernel fuzzy test seeds based on a large language model in an embodiment of the present application;

[0019] Figure 2 This is a schematic diagram of an embodiment of a system kernel fuzz test seed generation system based on a large language model in an embodiment of the present application. DETAILED DESCRIPTION

[0020] The embodiment of the present application provides a method and system for generating system kernel fuzz test seeds based on a large language model. The terms "first", "second", "third", "fourth", etc. (if any) in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments described here can be implemented in an order other than that illustrated or described here. In addition, the terms "including" or "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0021] For ease of understanding, the specific process of the embodiment of the present application is described below. Figure 1 In an embodiment of the present application, an embodiment of a method for generating system kernel fuzzy test seeds based on a large language model includes:

[0022] Step S101: extract features of Linux kernel system calls on a host machine to obtain a system call feature data set, where the system call feature data set includes call parameters, return value type, and abnormal status;

[0023] Step S102: Perform call relationship analysis on the system call feature data set based on the control flow graph CFG to obtain a system call sequence diagram, and perform dependency state extraction on the system call sequence diagram to obtain a state transition table;

[0024] Step S103: Perform test scenario construction processing on the state transition table to obtain a test scenario set, and use the Syzkaller tool to perform executable verification processing on the test scenario set to obtain a valid scenario library;

[0025] Step S104: performing seed use case generation processing on the valid scenario library to generate an initial seed use case set of the system call sequence, and performing execution test processing on the initial seed use case set through the Guest machine simulated by QEMU to obtain execution result data;

[0026] Step S105: Perform coverage analysis on the execution result data to obtain a coverage report, and optimize the seed test case according to the coverage report to obtain a target test case set.

[0027] It is understandable that the execution subject of the present application can be a system kernel fuzzy test seed generation system based on a large language model, or a terminal or a server, which is not limited here. The embodiment of the present application is described by taking the server as the execution subject as an example.

[0028] Specifically, the Linux kernel system call feature extraction process is performed on the host machine, and the Linux kernel system call is analyzed by the source code parser to generate the system call interface definition set. The feature extractor processes the system call interface definition set to identify the description information of the call parameters, return value type and abnormal state. The syntax analyzer semantically deconstructs the call parameters, obtains the value range constraints, generates the parameter constraint table through type deduction processing, and the semantic analyzer extracts the corresponding type rules from the parameter constraint table. The symbolic execution technology performs value range analysis on the return value type, constructs the return value constraint graph, and selects the valid return value type and the corresponding abnormal state information according to the path reachability judgment. The control flow analysis algorithm extracts the trigger condition sequence from the abnormal state information, combines the state machine theory to build the abnormal trigger model, and determines the abnormal state conversion rule through state transition analysis. The feature combiner generates a multidimensional feature matrix through cross-validation, and the constraint solver verifies the constraint satisfaction of the multidimensional feature matrix to generate a system call feature data set. Then, the system call feature data set is analyzed and processed based on the call relationship analysis of the control flow graph CFG. The control flow graph is a graphical representation of the program structure, in which each node represents a basic block and the edge represents a possible control flow transfer. The function call link is extracted from the system call feature data set to generate a call list. The call list is sorted by calling sequence arrangement to obtain a call timing relationship table. The call frequency statistics are performed on the call timing relationship table to generate a call frequency matrix. Then, the call frequency matrix is ​​weighted quantified by correlation analysis based on the control flow graph CFG to obtain a call weight table. According to the call weight table, a benchmark sequence diagram is constructed, and the benchmark sequence diagram is processed by node connection to generate a system call sequence diagram. The nodes in the system call sequence diagram are labeled with states to generate a state labeled sequence diagram. The state dependencies are extracted from the state labeled sequence diagram to obtain a state dependency table. The state dependency table is processed with state migration to output a state migration set. The state migration set is merged by path to obtain a conversion rule table. The conversion rule table is classified by rules to generate a state transition table. Then, the state transition table is processed for test scenario construction. Based on the large language model, the key state path is identified from the state transition table, the state path set is extracted, and the state path set is summarized by semantic analysis to obtain a state node sequence. The state node sequence is mapped to the control flow constraint space to generate a constraint condition table, which is then input into the large language model for semantic analysis and derivation to generate a scenario construction element set. According to the large language model, the scenario construction element set is combined in multiple dimensions to construct a benchmark scenario set. The benchmark scenario set is screened through conflict cross-validation to obtain a conflict-free scenario set. The integrity of the conflict-free scenario set is analyzed in combination with the rule library of the Syzkaller tool, and the test scenario set is output. The test scenario set is conditionally checked through environmental constraint verification to obtain a scenario condition list.Based on the scenario condition list, the resource occupancy is evaluated, the executable scenario set is screened, and the scenario similarity is clustered by the large language model to obtain the scenario feature vector. The scenario feature vector is projected into a high-dimensional semantic space, and the scenario is classified by density clustering. The clustering results are screened and sorted in combination with the scenario coverage metric to generate a valid scenario library.

[0029] Then, the seed use case generation process is performed on the effective scenario library, and the scenario feature parameters are extracted from the effective scenario library to construct a scenario parameter table. The parameter combination analysis of the scenario parameter table is performed through the large language model to obtain a parameter value set. The boundary conditions of the parameter value set are derived to generate a boundary test data table. The abnormal data injection into the boundary test data table is guided by the large language model to generate a test data set. The test data set is analyzed for sequence patterns, a use case template library is constructed, and the use case template library is filled with test data to generate an initial seed use case set of the system call sequence. The initial seed use case set is configured with the QEMU virtual environment. QEMU is an open source computer emulator and virtual machine. The test configuration table is output, and the task is assigned to the test configuration table through resource scheduling to obtain a test task sequence. The test task sequence is assigned to the guest machine for batch testing, and the program running track is recorded to generate a test running record. The state extraction and data collation of the test running record are performed to generate execution result data. Finally, the execution result data is covered and analyzed, and the code block marking process is performed on the execution result data to obtain an execution path tracking table. The execution path tracking table is subjected to path depth analysis to obtain a code coverage data set. Perform branch coverage statistics on the code coverage data set to obtain a branch coverage matrix, and perform uncovered point identification on the branch coverage matrix to obtain a coverage missing table. Perform trigger condition analysis on the coverage missing table to obtain a coverage report, and perform seed screening on the coverage report to obtain a core seed set. Perform path reconstruction on the core seed set through the reverse tracing algorithm to obtain a mutation direction table, and perform seed extension on the mutation direction table to obtain an extended seed sequence. Perform validity screening on the extended seed sequence to obtain a screening seed set, and perform sequence reorganization on the screening seed set through the path fusion algorithm to obtain the target test case set.

[0030] Taking the file system related system call test as an example, the file system related system calls in the Linux kernel, such as open, read, write, etc., are analyzed by the source code parser to extract their call parameter types (such as file path string, read and write buffer length, etc.), return value types (such as file descriptor, read and write bytes, etc.) and abnormal states (such as insufficient permissions, file does not exist, etc.). Based on this information, a control flow graph is constructed to analyze the dependencies between system calls, such as you must first call open to obtain a file descriptor before you can perform read or write operations. The large language model analyzes these dependencies and state transitions to construct complete test scenarios, such as creating files, writing data, reading verification, closing files, and other operation sequences. The executability of these scenarios is verified by the Syzkaller tool, and specific test cases are generated, such as opening a file with the path " / tmp / test.txt", writing 1024 bytes of data, and then reading to verify data integrity. These test cases are executed in the QEMU virtual machine, and code coverage is recorded, such as executing 80% of the code branches in the file system module. Based on the coverage analysis results, uncovered code areas, such as error handling paths, are identified. New test sequences are generated by mutating existing test cases, such as injecting illegal file paths or out-of-bounds read and write lengths. Ultimately, a comprehensive set of test cases is obtained to achieve in-depth testing of the file system code.

[0031] In the embodiment of the present application, the Linux kernel system call features are extracted on the Host host, and the system call feature data set formed includes complete call parameters, return value types and abnormal state information, which provides a comprehensive feature basis for subsequent tests and avoids the test blind spots caused by incomplete feature extraction in traditional methods. The system call sequence diagram is obtained by call relationship analysis based on the control flow graph CFG, and the dependent state is extracted to obtain the state transition table, which accurately grasps the dependency relationship and state transition law between system calls and improves the rationality of the test scenario. On this basis, the test scenario set is constructed using a large language model, and the executable verification is combined with the Syzkaller tool to obtain an effective scenario library, which gives full play to the semantic understanding ability of the large language model, and the generated test scenario is more in line with the actual use scenario. The seed case generation is performed on the effective scenario library, and the execution test is performed through the QEMU simulation environment to ensure the executability and effectiveness of the test case, and avoid the waste of resources caused by invalid testing. Finally, the target test case set is obtained through coverage analysis and optimization processing, which realizes the continuous optimization of the test case and the continuous improvement of the coverage rate. The overall solution realizes the intelligence and automation of system call testing by combining technologies such as large language models, control flow analysis, and virtualization testing, thereby improving testing efficiency and test coverage.

[0032] In a specific embodiment, the process of executing step S101 may specifically include the following steps:

[0033] (1) Based on the source code parser, the Linux kernel system call on the host machine is analyzed to generate a system call interface definition set. The feature extractor is used to identify the call parameters, return value type and abnormal status description information of the system call interface definition set;

[0034] (2) Use a syntax analyzer to semantically deconstruct the call parameters, obtain the value range constraints, generate a parameter constraint table through type inference, and extract the corresponding type rules from the parameter constraint table through a semantic analyzer;

[0035] (3) Perform value range analysis on the return value type, construct a return value constraint graph, and filter out valid return value types and their corresponding abnormal status information based on path reachability.

[0036] (4) Extract the trigger condition sequence from the abnormal state information based on the control flow analysis algorithm, build the abnormal trigger model in combination with the state machine theory, and determine the abnormal state transition rules through state transition analysis;

[0037] (5) Input the parameter constraint table, return value constraint diagram, and abnormal state conversion rules into the feature combiner to generate a multidimensional feature matrix through cross-validation;

[0038] (6) The constraint satisfaction of the multi-dimensional feature matrix is ​​verified by the constraint solver to generate a system call feature data set.

[0039] Specifically, a source code parser is a tool for analyzing program source code. It converts source code into an abstract syntax tree through lexical analysis and syntax analysis. The source code parser performs code analysis on the Linux kernel system call on the host, scans the source code file of the system call, extracts information such as function declaration, parameter definition, return value type, and generates a system call interface definition set. The feature extractor then processes this interface definition set. The feature extractor is a component specifically used to identify and extract specific program features. It identifies the description information of call parameters, return value type, and abnormal state through methods such as pattern matching and semantic analysis. The syntax analyzer receives this preliminary extracted information and performs semantic deconstruction on the call parameters. The syntax analyzer is an important component in compilation principle, which is used to analyze the syntax structure of the program and construct a syntax tree. In this solution, the syntax analyzer decomposes and reorganizes the type declaration, value range, constraint conditions, etc. of the parameter to obtain the value range constraint. The type inference processor generates a parameter constraint table based on these constraint information. The constraint table contains information such as the type, value range, validity condition, etc. of each parameter. The semantic analyzer extracts the corresponding type rules from the parameter constraint table. The semantic analyzer is responsible for understanding the semantic meaning of the program. It forms a complete set of type rules by analyzing the dependencies and mutually exclusive conditions between parameters.

[0040] Range analysis is a program analysis technique used to determine the possible value range of variables in a program. When performing range analysis on the return value type, the value space of the type is first established, and then the impact of the function execution path on the return value is considered to construct a return value constraint graph. The return value constraint graph is a directed graph structure, with nodes representing different return value states and edges representing transition conditions between states. Path reachability determination determines which return value states are reachable by analyzing the program control flow, thereby screening out valid return value types and their corresponding abnormal state information. The control flow analysis algorithm is a technique used to analyze the program execution process. In this solution, it is used to extract the trigger condition sequence from the abnormal state information. The algorithm constructs a control flow graph, analyzes the program execution path that leads to the abnormal state, and identifies the key conditions that trigger the exception. The state machine theory provides a formal method for describing the system state transition. Based on this theory, an abnormal trigger model is constructed, which contains normal states, abnormal states, and the transition relationship between states. The state transition analysis determines the abnormal state transition rules by simulating the system execution process. The rules describe under what conditions the system will transition from the normal state to the abnormal state.

[0041] The feature combiner integrates the parameter constraint table, return value constraint diagram, and abnormal state conversion rules. The feature combiner is a data fusion component that checks the relationship between these features through cross-validation. The cross-validation process includes checking whether the parameter values ​​meet the constraints, verifying whether the return value is compatible with the abnormal state, etc., and finally generating a multi-dimensional feature matrix. The constraint solver then verifies the constraint satisfaction of this multi-dimensional feature matrix. The constraint solver is a tool specifically used to solve constraint problems. It verifies whether the feature combination meets all constraints through mathematical reasoning methods, and finally generates a system call feature data set.

[0042] Taking the system calls related to network sockets as an example, the source code parser first analyzes the source code of system calls such as socket, bind, and listen, and extracts information such as function signatures and parameter types. For the socket function, the feature extractor identifies its three parameters: domain (communication domain), type (socket type), and protocol (protocol type), as well as the return value (file descriptor) and possible exception states (such as EAFNOSUPPORT, ENOMEM, etc.). The syntax analyzer deconstructs these parameters and finds that the valid values ​​of the domain parameter include AF_INET, AF_INET6, etc., and the type parameter includes SOCK_STREAM, SOCK_DGRAM, etc., thereby generating a parameter constraint table. The value domain analysis finds that the return value is either a file descriptor greater than or equal to 0, or an error code less than 0, and constructs a return value constraint graph. The control flow analysis finds that certain parameter combinations will trigger specific exceptions, such as when domain=AF_INET6 but the system does not support IPv6, it will trigger the EAFNOSUPPORT error, thus constructing an exception triggering model. The feature combiner integrates this information to generate a feature matrix containing all valid parameter combinations, return value conditions, and exception triggering rules. The constraint solver verifies the validity of these combinations, for example, ensuring that protocol cannot be set to IPPROTO_UDP when type=SOCK_STREAM, and finally generates a complete system call feature data set. This data set contains all legal parameter combinations, corresponding return value ranges, and possible exception states, providing a basis for subsequent test case generation.

[0043] In a specific embodiment, the process of executing step S102 may specifically include the following steps:

[0044] (1) Extract the function call link from the system call feature data set, generate a call list, sort the call list by calling sequence, and obtain the call timing relationship table;

[0045] (2) Perform call frequency statistics on the call timing relationship table to generate a call frequency matrix. Then, perform weight quantization on the call frequency matrix through correlation analysis based on the control flow graph (CFG) to obtain a call weight table.

[0046] (3) Construct a benchmark sequence graph based on the call weight table, perform node connection processing on the benchmark sequence graph, and generate a system call sequence graph;

[0047] (4) Annotate the nodes in the system call sequence diagram to generate a state annotation sequence diagram, and extract the dependency relationship between states from the state annotation sequence diagram to obtain a state dependency table;

[0048] (5) Perform state migration processing on the state dependency table, output a state migration set, and merge the paths of the state migration set to obtain a conversion rule table;

[0049] (6) Classify the rules in the conversion rule table and generate a state transition table.

[0050] Specifically, the function call link is extracted from the system call feature data set, that is, the call relationship between system calls is analyzed from the feature data set obtained in the previous step. The call list records the order of dependency of system calls. By analyzing the source code and runtime behavior, it identifies which system calls must be executed in a specific order. Call order sorting is to sort these call relationships according to the time order and degree of dependency, and generate a call timing relationship table, which records the predecessor and successor calls of each system call in a formatted manner. The call timing relationship table is counted for call frequency, and the number of times each system call is called during normal program execution is counted to generate a call frequency matrix. The call frequency matrix is ​​a two-dimensional matrix, where both rows and columns represent system calls, and the matrix elements represent the related frequencies between two calls. The call frequency matrix is ​​weighted quantized based on the correlation analysis of the control flow graph CFG. The control flow graph is a directed graph that represents the program execution process, in which each node represents a basic block and the edge represents a possible execution path. The correlation analysis calculates the call weight using the following formula:

[0051]

[0052] in: represents the weight between system calls i and j, Indicates the calling frequency. Indicates the call depth, represents the path complexity, , , is the weight coefficient, , , are the maximum values ​​of the corresponding indicators respectively.

[0053] The benchmark sequence diagram is constructed based on the calculated call weight table. The benchmark sequence diagram is a preliminary system call sequence framework. The benchmark sequence diagram is processed by node connection, and the connection relationship between nodes is determined according to the weight value to generate a complete system call sequence diagram. The system call sequence diagram clearly shows the execution order and dependency relationship between system calls. Then, the nodes in the system call sequence diagram are annotated with states, including the system state before the call, the state change after the call, and the possible abnormal state, to generate a state annotated sequence diagram. The state annotated sequence diagram contains not only the call sequence, but also the state information of each call point. The dependency relationship between states is extracted from the state annotated sequence diagram, and the transition conditions and constraint relationships between different states are analyzed to obtain the state dependency table. The state dependency table records the preconditions and postconditions of state transitions.

[0054] Perform state migration processing on the state dependency table, analyze the possible migration paths between each state, and output the state migration set. The state migration set contains all possible state transition sequences. Perform path merging on the state migration set, merge and simplify the paths with similar migration conditions and results, and obtain the conversion rule table. The conversion rule table summarizes and summarizes the state migration rules. Finally, classify the rules of the conversion rule table, classify and organize similar conversion rules, and generate a state transition table. The state transition table is a structured document that clearly describes the state transition rules during the execution of the system call.

[0055] Taking the system calls related to process management as an example, we first extract the call links of system calls such as fork, exec, and wait from the feature data set. Analysis shows that fork must be called before exec, and wait must be called after the child process is created, and a call list is generated accordingly. The timing relationship table is obtained by sorting the call sequence, such as the basic sequence of fork->exec->wait. Statistical analysis shows that in actual applications, fork-exec has the highest call frequency, accounting for 85% of the total number of calls, while the single fork call accounts for 10%, and the remaining 5% is other combinations. When calculating the weight through control flow graph analysis, considering that the execution path of the fork-exec sequence is short and stable, the weight value is higher, while the subsequent path of the single fork is more complex and the weight value is lower. A benchmark sequence diagram is constructed based on the weight value, and fork-exec is used as the main path. When connecting nodes, the dependency of wait is taken into account to generate a complete call sequence diagram. When annotating the state, the creation, execution, termination and other states of the process, as well as various abnormal conditions such as insufficient memory and insufficient permissions, are recorded. When extracting the state dependency, it is found that the wait state depends on the existence of the child process, and the exec state depends on the successful execution of fork. Perform state transition analysis to obtain a complete state transition sequence from process creation to termination. Finally, classify the transition rules, classify the normal execution path, resource-restricted path, and permission-restricted path, and form a complete state transition table. This state transition table provides an important reference for the subsequent generation of test cases.

[0056] In a specific embodiment, the process of executing step S103 may specifically include the following steps:

[0057] (1) Based on the large language model, the key state path is identified from the state transition table, the state path set is extracted, and the state path set is summarized by nodes through semantic parsing to obtain the state node sequence;

[0058] (2) Map the state node sequence to the control flow constraint space to generate a constraint table, which is then input into the large language model for semantic analysis and derivation to generate a scene construction element set;

[0059] (3) Based on the large language model, the scene construction element set is combined in multiple dimensions to construct a benchmark scene set. The benchmark scene set is screened through conflict cross-validation to obtain a conflict-free scene set.

[0060] (4) Combine the Syzkaller rule library to perform integrity analysis on the conflict-free scenario set, output the test scenario set, and perform conditional check on the test scenario set through environmental constraint verification to obtain a scenario condition list;

[0061] (5) Evaluate resource usage based on the scenario condition list, screen the executable scenario set, and then use the large language model to cluster the scenario similarities to obtain the scenario feature vector;

[0062] (6) Project the scene feature vector into a high-dimensional semantic space, classify the scenes through density clustering, and filter and sort the clustering results based on the scene coverage metric to generate a valid scene library.

[0063] Specifically, the key state paths are identified from the state transition table through the large language model. The large language model uses a deep learning algorithm to analyze the state descriptions and transition rules in the state transition table to find the core state paths that have the greatest impact on system behavior. The extracted state path set contains all important state transition sequences. These paths are node-inducing through semantic parsing technology, and similar state nodes are merged and simplified to finally obtain a streamlined state node sequence. The state node sequence is then mapped to the control flow constraint space, which is a mathematical space that describes the constraints of the program execution process. The mapping process establishes the correspondence between the state nodes and the program execution conditions and generates a constraint table. The constraint table is input into the large language model for semantic analysis and derivation, and the actual meaning of the constraints is understood through natural language processing technology, thereby generating a scenario construction element set. The scenario construction element set contains various basic elements required to build a test scenario.

[0064] The large language model performs multi-dimensional combination based on the scenario construction element set. The multi-dimensional combination takes into account multiple dimensions such as parameter values, execution order, resource conditions, etc. to construct a benchmark scenario set. Conflict cross-validation performs conflict detection on the scenarios in the benchmark scenario set to verify whether the operation sequences in the scenarios conflict or are incompatible with each other, and obtains a conflict-free scenario set through screening. Syzkaller is a Linux kernel fuzz testing tool with a rich test rule library. Combined with the Syzkaller rule library, the integrity analysis of the conflict-free scenario set is performed to check whether the scenario complies with the system call usage specifications and output a standardized test scenario set. Environmental constraint verification checks the feasibility of these test scenarios in the actual execution environment, including resource restrictions, permission requirements and other constraints, and generates a list of scenario conditions.

[0065] When evaluating the resource usage of the scenario condition list, the resource score is calculated using the following formula:

[0066]

[0067] in: They represent the resource occupancy score, Indicates CPU usage. Indicates memory usage. Indicates time consumption, Indicates bandwidth usage. , Indicates the corresponding resource limit, , , is the weight coefficient, is the penalty factor, and n is the number of resource types.

[0068] Based on the scoring results, a set of executable scenarios with reasonable resource usage is screened out, and then the large language model performs similarity clustering analysis on these scenarios to obtain the scenario feature vector. The scenario feature vector contains the key feature information of the scenario. The scenario feature vector is projected into a high-dimensional semantic space, which can better express the semantic relationship between scenarios. The projected feature vector is clustered using a density clustering algorithm. Density clustering is a density-based clustering method that can discover clusters of any shape. The clustering results are evaluated and sorted in combination with the scenario coverage metric, and finally a valid scenario library is generated.

[0069] Taking the memory management system call as an example, the large language model first identifies key state paths such as memory allocation, access, and release from the state transition table. For example, mmap calls for memory allocation, memory page access, and munmap calls for memory release. Semantic parsing summarizes these paths into a basic state node sequence of "allocation-use-release". When mapped to the control flow constraint space, constraints including memory size limits, page alignment requirements, and access rights are generated. The large language model analyzes these constraints and generates scenario construction elements including memory size, protection flags, and mapping types. Multi-dimensional combinations generate test scenarios with different memory sizes (such as 4KB to 2MB), different access rights (such as read-only, read-write), and different mapping types (such as private mappings and shared mappings). Conflict checking finds and removes conflicting scenarios such as repeated mappings of the same address area. Syzkaller rule verification ensures that the mmap parameters in the scenario are legal, such as alignment requirements, flag bit combinations, etc. Environmental constraint checking takes into account conditions such as system memory limits and process address space limits. Resource occupancy assessment calculates the memory occupancy of each scenario. For example, a 2MB private mapping has a small initial occupancy, but copy-on-write will cause the actual occupancy to increase. Similarity clustering groups similar memory operation scenarios (such as similar size and permissions) into a group, and finally selects a set of test scenarios covering different memory operation characteristics.

[0070] In a specific embodiment, the process of executing step S104 may specifically include the following steps:

[0071] (1) Extract scene feature parameters from the effective scene library, construct a scene parameter table, and perform parameter combination analysis on the scene parameter table through a large language model to obtain a parameter value set;

[0072] (2) Derivation of boundary conditions for the parameter value set to generate a boundary test data table. Abnormal data is injected into the boundary test data table through the guidance of the large language model to generate a test data set.

[0073] (3) Perform sequence pattern analysis on the test data set, construct a use case template library, and fill the use case template library with test data to generate an initial seed use case set of the system call sequence;

[0074] (4) Configure the QEMU virtual environment for the initial seed use case set, output the test configuration table, assign tasks to the test configuration table through resource scheduling, and obtain the test task sequence;

[0075] (5) Assign the test task sequence to the guest machine for batch testing, record the program running trajectory, and generate the test running record;

[0076] (6) Extract the status and organize the data of the test operation records to generate execution result data.

[0077] Specifically, the scenario feature parameters include the parameter type, value range, constraints and other information of the system call, which are organized into a structured scenario parameter table. The large language model analyzes the scenario parameter table, understands the correlation between parameters through natural language processing and deep learning technology, generates reasonable parameter combinations, and forms a parameter value set. When deriving boundary conditions for the parameter value set, the main focus is on the limit values ​​and critical states of the parameters. The boundary condition derivation is based on the type and constraints of the parameters. For example, for integer parameters, special values ​​such as maximum value, minimum value, and zero value are considered, and for string parameters, empty string, maximum length and other situations are considered to generate a boundary test data table. Based on the understanding of system call behavior, the large language model specifically injects abnormal data into the boundary test data table, such as out-of-bounds values, illegal characters, special encodings, etc., to generate a comprehensive test data set.

[0078] The test data set is subjected to sequence pattern analysis, which is a technique for mining common patterns in data sequences. By analyzing the typical usage patterns of system calls, representative call sequence templates are extracted to construct a test case template library. The templates in the test case template library define the basic organization of system calls, including call order, parameter dependency, status check and other elements. The test data is filled into these templates to generate specific system call sequences to form an initial seed test case set. The initial seed test case set needs to be tested in the QEMU virtual environment. QEMU is an open source hardware virtualization simulator that can provide an independent test environment. The QEMU environment is configured for the seed test case set, including setting parameters such as virtual machine specifications, memory size, and number of CPU cores, and generating a test configuration table. The resource scheduler analyzes resource requirements based on the test configuration table, reasonably allocates test tasks, and generates a test task sequence. Resource scheduling takes into account factors such as task priority, resource consumption, and execution time.

[0079] The test task sequence is assigned to the Guest virtual machine for execution. The Guest is a test environment running in QEMU. During the test execution, the recorder captures the program's running trajectory in real time, including the execution order of system calls, return values, exception information, etc., and generates a detailed test run record. After state extraction and data collation, the test run record converts the original execution log into a structured data format to generate standardized execution result data. Taking the system call test related to file operations as an example, the characteristic parameters of system calls such as open, read, and write are first extracted from the effective scenario library. The parameters of the open call include file path, access mode, permission flag, etc., and the parameters of the read and write calls include file descriptors, buffer sizes, etc. The large language model analyzes these parameters and generates different parameter combinations, such as using relative paths and absolute paths for file paths, and combining read-only, write-only, and read-write permissions for access modes to generate parameter value sets.

[0080] Boundary condition derivation generates boundary test data for these parameters, such as the file path length is 4096 bytes (the path length limit of a typical system), the permissions are set to 0777 (maximum permissions) and 0000 (no permissions), the buffer size is 1 byte (minimum) and 16MB (larger value), etc. The large language model injects abnormal data, such as illegal path characters " / .. / ..", negative buffer sizes, out-of-bounds file descriptors, etc. Sequence pattern analysis constructs typical file operation templates, such as the basic read and write template of "open-read-write-close", the memory mapping template of "open-mmap-memcpy-munmap-close", etc. Fill the test data into the template to generate a specific test sequence, such as opening the / tmp / test.txt file, trying to read 16MB of data, writing 1KB of random data, and finally closing the file.

[0081] When configuring the QEMU environment, 2GB of memory and 2 CPU cores were allocated to run the test, and the guest machine ran a streamlined Linux system. Resource scheduling executed the test tasks in batches of 500 test cases. The test process recorded the execution results of each system call, including return values ​​(such as the file descriptor returned by open), error codes (such as ENOENT indicating that the file does not exist), execution time, and other information. The final execution result data contains a complete record of the test process, providing basic data for subsequent coverage analysis and test case optimization.

[0082] In a specific embodiment, the process of executing step S105 may specifically include the following steps:

[0083] (1) Perform code block marking on the execution result data to obtain an execution path tracking table, and perform path depth analysis on the execution path tracking table to obtain a code coverage data set;

[0084] (2) Perform branch coverage statistics on the code coverage data set to obtain a branch coverage matrix, and perform uncovered point identification on the branch coverage matrix to obtain a coverage missing table;

[0085] (3) Perform trigger condition analysis on the coverage missing table to obtain a coverage report, and perform seed screening on the coverage report to obtain a core seed set;

[0086] (4) Reconstruct the path of the core seed set through the reverse tracing algorithm to obtain a mutation direction table, and perform seed expansion on the mutation direction table to obtain an extended seed sequence;

[0087] (5) The extended seed sequence is screened for validity to obtain a screened seed set, and the screened seed set is reorganized through a path fusion algorithm to obtain a target test case set.

[0088] Specifically, the execution result data is processed by code block marking, and marking points are set at key positions of the code through the stub technology to record the actual execution path of each test case. The marking points include key positions such as function entry, branch points, loop points, etc. Each marking point records the context information during execution, such as call stack, parameter value, return value, etc. These execution path information are recorded in the execution path tracking table, and each record contains the test case identification, execution sequence, and marking point information. The execution path tracking table is deeply analyzed to count the number of executions, execution order, and execution conditions of each code block, so as to construct a complete code coverage data set. The code coverage data set is subjected to branch coverage statistics to analyze the execution of each conditional branch. Branch coverage includes true branches and false branches of conditional statements, entry and exit of loop statements, normal paths and abnormal paths of exception handling, etc. The statistical results generate a branch coverage matrix, and each element in the matrix represents the coverage of the corresponding branch. By analyzing the branch coverage matrix, the code branches that are not covered by any test case are identified. These uncovered points are recorded in the coverage missing table, which contains information such as branch position, branch type, and function to which they belong.

[0089] The trigger conditions of each uncovered point in the coverage missing table are analyzed to study the necessary conditions that lead to the execution of these branches. The trigger conditions include the value requirements of the input parameters, the constraints of the program state, the setting requirements of the environment variables, etc. The analysis results are organized into a coverage report, which records in detail the proportion of covered branches, the distribution of uncovered branches, the coverage of critical paths, etc. Based on the coverage report, representative test cases are screened out, which cover important program paths or trigger special execution conditions, and the core seed set is generated. The core seed set is analyzed by the reverse tracing algorithm, starting from the test cases that generate the expected coverage, and the direction of the change of the input conditions is reversely deduced. The reverse tracing process includes tracing back from the target branch to the input point, analyzing the constraints on the path, and determining the direction and amplitude of the parameter adjustment. These mutation guidance information are recorded in the mutation direction table to guide the subsequent seed expansion. Based on the mutation direction table, the core seeds are expanded, and new test cases are generated by adjusting parameter values, modifying input conditions, changing the execution order, etc., to generate an extended seed sequence.

[0090] The validity of the extended seed sequence is evaluated to verify whether the newly generated test cases meet the execution conditions and whether they will lead to invalid or redundant tests. The validity check includes parameter validity, state consistency, resource availability and other aspects. The screening seed set is generated through the checked cases. Finally, the screening seed set is reorganized through the path fusion algorithm, multiple similar test paths are merged, the structure of the test sequence is optimized, and an efficient target test case set is generated. Take the test of the process communication API as an example: for the shared memory communication function interface, the execution path tracking shows that the key code blocks include memory mapping, data reading and writing, synchronization control and other parts. Statistics show that the code coverage rate of basic read and write operations reaches 90%, the error handling coverage rate of memory mapping is 60%, and the exception handling coverage rate of the synchronization mechanism is only 40%. Branch coverage analysis shows that the uncovered situations mainly occur in branches such as concurrent access conflicts, memory out-of-bounds checks, and resource release exceptions.

[0091] Analysis of trigger conditions shows that: covering concurrent conflict branches requires two processes to access the same memory area at the same time; covering memory out-of-bounds checks requires access addresses outside the mapping range; covering resource release exceptions requires forced release when resources are occupied. Core seeds were selected from existing test cases: Use case A implemented basic read and write operations; Use case B triggered memory mapping failure; Use case C tested basic concurrent access. Through reverse tracing, the expansion direction was determined: for use case A, large data transmission was tested by increasing the data block size (from 4KB to 8KB); for use case B, memory mapping parameters were modified (from read-only to read-write) to cover different permission combinations; for use case C, process scheduling timing was adjusted (introducing random delays of 0-100ms) to increase the probability of concurrent conflicts. After expansion, a new test sequence was generated, and after validity checks, use cases that can stably reproduce the problem were selected. Through path fusion, use cases that test the same function but different parameters were merged to generate a compact test set, with coverage increased to 95%, especially in concurrency control and exception handling.

[0092] In a specific embodiment, the process of performing path reconstruction processing on the core seed set through a reverse tracing algorithm to obtain a variation direction table, and performing seed expansion processing on the variation direction table to obtain an expanded seed sequence step may specifically include the following steps:

[0093] (1) Perform path call extraction processing on the core seed set to obtain a path call table, and perform node reverse labeling processing on the path call table to obtain a reverse labeling sequence;

[0094] (2) Perform conditional constraint extraction on the reverse tag sequence to obtain a constraint list, and perform path reachability determination on the constraint list to obtain a reachable path set;

[0095] (3) Relax the constraints of the reachable path set to obtain a relaxation parameter table, and conditionally mutate the relaxation parameter table to obtain a mutation rule set;

[0096] (4) Performing rule sorting processing on the variation rule set to obtain a rule priority table, and performing direction extraction processing on the rule priority table to obtain a variation direction table;

[0097] (5) performing parameter value generation processing on the mutation direction table to obtain a mutation parameter set, and performing data reorganization processing on the mutation parameter set to obtain an extended seed set;

[0098] (6) The extended seed group is serialized to obtain a candidate seed sequence, and the candidate seed sequence is subjected to feasibility evaluation to obtain an extended seed sequence.

[0099] Specifically, the execution path information of each seed use case is extracted, and key nodes such as function call sequence, branch selection, condition judgment, etc. are recorded to generate a path call table. Each record in the path call table contains node identification, call type, parameter information, etc. The nodes in the path call table are reversely marked, and the predecessor nodes and influencing conditions of each node are traced back from the execution end to the starting point, and a reverse marking sequence containing complete dependencies is generated. Condition constraint analysis is performed on each node in the reverse marking sequence to extract the combination of conditions required to trigger the execution of the node. These conditions include the range of input parameter values, execution state requirements, resource conditions, etc. All constraints are sorted into a constraint linked list in the order of dependency. Path reachability analysis is performed on the constraint linked list to verify whether there is a legal execution path from the initial state to the target state, and the combination of conditions that need to be met to reach the path, and a reachable path set is generated.

[0100] The constraints in the reachable path set are relaxed, and the restrictions of some conditions are appropriately relaxed. Constraint relaxation includes expanding the range of parameter values, reducing resource requirements, simplifying state conditions, etc. These relaxation rules are recorded in the relaxation parameter table. The conditions in the relaxation parameter table are mutated, and new parameter combinations and test conditions are generated according to the relaxation rules. A mutation rule set is generated to guide the subsequent test case generation. Prioritize the mutation rule set, consider factors such as the importance of the rules, coverage effect, and execution cost, and generate a rule priority table. Direction extraction is performed on the rule priority table, and the mutation direction and mutation amplitude guided by each rule are analyzed and recorded in the mutation direction table to provide guidance for parameter generation. New parameter values ​​are generated based on the mutation direction table, and the parameter combinations are generated into a mutation parameter set. Data is reorganized for the mutation parameter set, and parameter values ​​are organized according to the test objectives to generate an extended seed group.

[0101] The extended seed group is structured, and the information such as test parameters, execution conditions, and expected results are organized into a standard format to generate a candidate seed sequence. The feasibility of the candidate seed sequence is evaluated to verify whether each test case in the sequence meets the execution conditions and can produce effective test results, so as to generate a reliable extended seed sequence.

[0102] The above describes the system kernel fuzzy test seed generation method based on the large language model in the embodiment of the present application. The following describes the system kernel fuzzy test seed generation system based on the large language model in the embodiment of the present application. Figure 2 In an embodiment of the present application, an embodiment of a system kernel fuzzy test seed generation system based on a large language model includes:

[0103] The collection module 201 is used to perform feature extraction processing on the Linux kernel system call on the Host host to obtain a system call feature data set, which includes call parameters, return value type and abnormal status;

[0104] The analysis module 202 is used to perform call relationship analysis processing on the system call feature data set based on the control flow graph CFG to obtain a system call sequence diagram, and perform dependency state extraction processing on the system call sequence diagram to obtain a state transition table;

[0105] A construction module 203 is used to perform a test scenario construction process on the state transition table to obtain a test scenario set, and use a Syzkaller tool to perform an executable verification process on the test scenario set to obtain a valid scenario library;

[0106] The generation module 204 is used to perform seed use case generation processing on the effective scenario library, generate an initial seed use case set of the system call sequence, and perform execution test processing on the initial seed use case set through the guest machine simulated by QEMU to obtain execution result data;

[0107] The optimization module 205 is used to perform coverage analysis on the execution result data to obtain a coverage report, and optimize the seed test case according to the coverage report to obtain a target test case set.

[0108] Through the cooperation of the above components, the Linux kernel system call features are extracted on the host machine. The system call feature data set formed contains complete call parameters, return value types and abnormal status information, which provides a comprehensive feature basis for subsequent tests and avoids the test blind spots caused by incomplete feature extraction in traditional methods. The system call sequence diagram is obtained by analyzing the call relationship based on the control flow graph CFG, and the dependent state is extracted to obtain the state transition table, which accurately grasps the dependency relationship and state transition law between system calls and improves the rationality of the test scenario. On this basis, the test scenario set is constructed using the large language model, and the executable verification is combined with the Syzkaller tool to obtain an effective scenario library, which gives full play to the semantic understanding ability of the large language model, and the generated test scenarios are more in line with the actual use scenarios. Seed cases are generated for the effective scenario library, and the execution test is performed through the QEMU simulation environment to ensure the executability and effectiveness of the test cases and avoid the waste of resources caused by invalid tests. Finally, the target test case set is obtained through coverage analysis and optimization processing, which realizes the continuous optimization of test cases and the continuous improvement of coverage. The overall solution realizes the intelligence and automation of system call testing by combining technologies such as large language models, control flow analysis, and virtualization testing, thereby improving testing efficiency and test coverage.

[0109] As described above, the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A system kernel fuzz test seed generation method based on a large language model, characterized in that: The system kernel fuzz test seed generation method based on a large language model includes: Perform feature extraction on the Linux kernel system call on the Host to obtain a system call feature data set, where the system call feature data set includes call parameters, return value type, and abnormal status; Performing call relationship analysis processing based on a control flow graph CFG on the system call feature data set to obtain a system call sequence diagram, and performing dependency state extraction processing on the system call sequence diagram to obtain a state transition table; Performing a test scenario construction process on the state transition table to obtain a test scenario set, and performing an executable verification process on the test scenario set using a Syzkaller tool to obtain a valid scenario library; Perform seed use case generation processing on the effective scenario library to generate an initial seed use case set of the system call sequence, and perform execution test processing on the initial seed use case set through a guest machine simulated by QEMU to obtain execution result data; The execution result data is subjected to coverage analysis to obtain a coverage report, and the seed test case is optimized according to the coverage report to obtain a target test case set.

2. The method for generating system kernel fuzzy test seeds based on a large language model according to claim 1, characterized in that: The Linux kernel system call is subjected to feature extraction processing on the Host host to obtain a system call feature data set, wherein the system call feature data set includes call parameters, return value type and abnormal status, including: Perform code analysis on the Linux kernel system call on the Host host based on a source code parser to generate a system call interface definition set, and identify call parameters, return value types, and description information of abnormal states of the system call interface definition set through a feature extractor; A syntax analyzer is used to semantically deconstruct the call parameters to obtain value range constraints, a parameter constraint table is generated through type deduction processing, and a semantic analyzer is used to extract corresponding type rules from the parameter constraint table; Performing a value range analysis on the return value type, constructing a return value constraint graph, and filtering out valid return value types and their corresponding abnormal state information based on path reachability; Extracting the trigger condition sequence from the abnormal state information according to the control flow analysis algorithm, building the abnormal trigger model in combination with the state machine theory, and determining the abnormal state conversion rule through state transition analysis; Input the parameter constraint table, return value constraint diagram and abnormal state conversion rules into a feature combiner, and generate a multi-dimensional feature matrix by cross-validation; The constraint satisfaction of the multi-dimensional feature matrix is ​​verified according to the constraint solver to generate a system call feature data set.

3. The system kernel fuzz test seed generation method based on a large language model according to claim 1 is characterized in that: The system call feature data set is subjected to call relationship analysis based on a control flow graph CFG to obtain a system call sequence diagram, and the system call sequence diagram is subjected to dependency state extraction processing to obtain a state transition table, including: Extracting function call links from the system call feature data set, generating a call linked list, and sorting the call linked list by calling sequence to obtain a call timing relationship table; Performing call frequency statistics on the call timing relationship table to generate a call frequency matrix, and then weight quantizing the call frequency matrix through correlation analysis based on the control flow graph CFG to obtain a call weight table; Construct a benchmark sequence graph according to the call weight table, perform node connection processing on the benchmark sequence graph, and generate a system call sequence graph; Performing state annotation on nodes in the system call sequence diagram to generate a state annotation sequence diagram, and extracting dependencies between states from the state annotation sequence diagram to obtain a state dependency table; Performing state migration processing on the state dependency table, outputting a state migration set, and performing path merging on the state migration set to obtain a conversion rule table; The conversion rule table is classified into rules to generate a state conversion table.

4. The method for generating system kernel fuzzy test seeds based on a large language model according to claim 1, characterized in that: The state transition table is subjected to a test scenario construction process to obtain a test scenario set, and the test scenario set is subjected to an executable verification process using a Syzkaller tool to obtain a valid scenario library, including: Based on the large language model, a key state path is identified from the state transition table, a state path set is extracted, and node induction is performed on the state path set through semantic parsing to obtain a state node sequence; Mapping the state node sequence to the control flow constraint space, generating a constraint condition table, and then inputting the large language model for semantic analysis and derivation to generate a scene construction element set; Combining the scene construction element set in multiple dimensions according to the large language model to construct a reference scene set, and screening the reference scene set through conflict cross-validation to obtain a conflict-free scene set; Performing integrity analysis on the conflict-free scenario set in combination with the Syzkaller rule library, outputting a test scenario set, and performing conditional check on the test scenario set through environmental constraint verification to obtain a scenario condition list; Based on the scenario condition list, resource occupancy evaluation is performed, an executable scenario set is screened, and then scenario similarity clustering is performed using a large language model to obtain a scenario feature vector; The scene feature vector is projected into a high-dimensional semantic space, the scenes are classified by density clustering, and the clustering results are screened and sorted in combination with scene coverage metrics to generate a valid scene library.

5. The method for generating system kernel fuzzy test seeds based on a large language model according to claim 1, characterized in that: The seed use case generation process is performed on the effective scenario library to generate an initial seed use case set of the system call sequence, and the initial seed use case set is executed and tested by the Guest machine simulated by QEMU to obtain execution result data, including: Extracting scene feature parameters from the effective scene library, constructing a scene parameter table, and performing parameter combination analysis on the scene parameter table through a large language model to obtain a parameter value set; Deducing boundary conditions for the parameter value set to generate a boundary test data table, injecting abnormal data into the boundary test data table through the guidance of a large language model to generate a test data set; Performing sequence pattern analysis on the test data set, constructing a use case template library, and filling the use case template library with test data to generate an initial seed use case set of the system call sequence; Perform QEMU virtual environment configuration on the initial seed use case set, output a test configuration table, and perform task allocation on the test configuration table through resource scheduling to obtain a test task sequence; Allocate the test task sequence to the Guest machine for batch testing, record the program running track, and generate a test running record; The test run record is subjected to status extraction and data collation to generate execution result data.

6. The method for generating system kernel fuzzy test seeds based on a large language model according to claim 1, characterized in that: The performing coverage analysis on the execution result data to obtain a coverage report, and optimizing the seed test case according to the coverage report to obtain a target test case set, including: Performing code block marking processing on the execution result data to obtain an execution path tracking table, and performing path depth analysis processing on the execution path tracking table to obtain a code coverage data set; Performing branch coverage statistics processing on the code coverage data set to obtain a branch coverage matrix, and performing uncovered point identification processing on the branch coverage matrix to obtain a coverage missing table; Performing trigger condition analysis on the coverage missing table to obtain a coverage report, and performing seed screening on the coverage report to obtain a core seed set; Performing path reconstruction processing on the core seed set through a reverse tracing algorithm to obtain a variation direction table, and performing seed expansion processing on the variation direction table to obtain an extended seed sequence; The extended seed sequence is subjected to validity screening to obtain a screening seed set, and the screening seed set is subjected to sequence recombination processing through a path fusion algorithm to obtain a target test case set.

7. The method for generating system kernel fuzzy test seeds based on a large language model according to claim 6, characterized in that: The process of performing path reconstruction processing on the core seed set by a reverse tracing algorithm to obtain a variation direction table, and performing seed expansion processing on the variation direction table to obtain an extended seed sequence includes: Performing path call extraction processing on the core seed set to obtain a path call table, and performing node reverse marking processing on the path call table to obtain a reverse marking sequence; Performing conditional constraint extraction processing on the reverse tag sequence to obtain a constraint linked list, and performing path reachability determination processing on the constraint linked list to obtain a reachable path set; Performing constraint relaxation processing on the reachable path set to obtain a relaxation parameter table, and performing conditional mutation processing on the relaxation parameter table to obtain a mutation rule set; Performing rule sorting processing on the variation rule set to obtain a rule priority table, and performing direction extraction processing on the rule priority table to obtain a variation direction table; Performing parameter value generation processing on the variation direction table to obtain a variation parameter set, and performing data reorganization processing on the variation parameter set to obtain an extended seed group; The extended seed group is subjected to serialization processing to obtain a candidate seed sequence, and the candidate seed sequence is subjected to feasibility evaluation processing to obtain an extended seed sequence.

8. A system kernel fuzzy test seed generation system based on a large language model, used to implement the system kernel fuzzy test seed generation method based on a large language model as described in any one of claims 1-7, characterized in that: The system kernel fuzz test seed generation system based on a large language model includes: The acquisition module is used to perform feature extraction processing on the Linux kernel system call on the Host host to obtain a system call feature data set, wherein the system call feature data set includes call parameters, return value type and abnormal status; An analysis module is used to perform call relationship analysis processing on the system call feature data set based on a control flow graph CFG to obtain a system call sequence diagram, and perform dependency state extraction processing on the system call sequence diagram to obtain a state transition table; A construction module is used to perform a test scenario construction process on the state transition table to obtain a test scenario set, and use a Syzkaller tool to perform an executable verification process on the test scenario set to obtain a valid scenario library; A generation module is used to perform seed use case generation processing on the effective scenario library, generate an initial seed use case set of the system call sequence, and perform execution test processing on the initial seed use case set through a guest machine simulated by QEMU to obtain execution result data; The optimization module is used to perform coverage analysis on the execution result data to obtain a coverage report, and optimize the seed test case according to the coverage report to obtain a target test case set.

Images