An intelligent detection method for a QEMU component digital model

Abstract

The application provides an intelligent detection method for a QEMU component digital model, and belongs to the technical field of software testing and source code defect detection, and specific steps are as follows: 1, obtaining the source code of the QEMU component digital model; 2, based on the abstract syntax tree of the source code, according to the definition of the source code defect rule, matching the source code defect in the QEMU component digital model; 3, according to the extension graph of the source code generation program, combining the symbolic execution technology to analyze the path dependence of the source code, and detecting the potential source code defects dependent on the execution path; 4, detecting the source code through the deep learning model to obtain the detection result, and confirming whether the source code defects of steps 2 and 3 are correct according to the detection result. Through the processing scheme of the application, the problems of high false positive rate and incomplete defect type detection in the existing detection method are solved.

Description

Technical Field

[0001] The present application relates to the field of software testing and source code defect detection, and in particular to an intelligent detection method for QEMU component digital models. Background Art

[0002] During the software development process, many software defects are inevitably introduced. These software defects may be caused by non-standard coding, and serious ones may cause system crashes. For example, declarations and definitions, control statements, function usage, pointers and resources, expressions, etc. in the software source code often cause array out-of-bounds, arithmetic overflow, division by zero, pointer errors, and data contention.

[0003] To ensure software quality and the safe and stable operation of the system, it is extremely necessary to strictly detect and correct defects hidden in the software. Traditional static analysis tools based on source code require a lot of manpower and time costs, and have low detection efficiency and accuracy. Summary of the Invention

[0004] In view of this, the present application provides an intelligent detection method for the digital model of QEMU components to solve the problems of high false alarm rate and incomplete detection of defect types in existing detection methods.

[0005] This application provides an intelligent detection method for QEMU component digital models using the following technical solutions:

[0006] An intelligent detection method for QEMU component digital models, comprising:

[0007] Step 1: Get the source code of the QEMU component digital model;

[0008] Step 2: Based on the abstract syntax tree of the source code and according to the definition of source code defect rules, match the source code defects in the QEMU component digital model;

[0009] Step 3: Generate an extension graph of the program based on the source code, and perform path dependency analysis on the source code using symbolic execution technology to detect potential source code defects that depend on the execution path.

[0010] Step 4 uses a deep learning model to detect the source code and obtain the detection results. Based on the detection results, it is confirmed whether the source code defects in steps 2 and 3 are correct.

[0011] Optionally, step 1 specifically includes:

[0012] During the compilation process, based on the fact that the QEMU component digital model uses the Makefile compilation tool chain, the build information is collected by directly running the Makefile or simulating the build, obtaining the list of source files that need to be analyzed, the compilation options of the source files, the header file search path, and the key information of predefined macros;

[0013] Get the source code to be tested by combining the source file list, source file compilation options, header file search path and predefined macro key information;

[0014] The source code to be tested is replaced with the original code by predefined macros and header file inclusions according to the header file search path and predefined macro key information, and then a complete source code to be tested is formed. The complete source code to be tested is scanned and the source code file is converted into an abstract syntax tree AST.

[0015] Optionally, step 1 further includes:

[0016] The characteristics of the digital models of QEMU components are analyzed, and a set of detection rules suitable for QEMU components is organized and constructed by combining some existing rule sets.

[0017] Optionally, step 2 specifically includes:

[0018] Use the abstract syntax tree to build a matching object corresponding to the source code. Combine the class implemented by the matching object with the source code defect rules to match and obtain the source code defects detected based on the abstract syntax tree:

[0019] During the scanning of the complete source code to be tested, when the #if and #endif preprocessing statements are scanned, the registered PPCallbacks class in the preprocessor of the analysis engine is called, and the overloaded function for the preprocessing instructions added in the preprocessing stage by the registerPPCallbacks function is used to detect source code defects based on preprocessing instructions; when analyzing the file units in the source code, the onStartOfTranslationUnit function is used to initialize and allocate storage space when entering the file unit, and statistics are collected and written to the storage space when performing abstract syntax tree matching. When the file unit analysis ends, the onEndOfTranslationUnit function is called, and analysis is performed based on the content in the storage space to obtain source code defects detected based on file unit statistics;

[0020] During the scanning process of the complete source code to be tested, an interface for obtaining the original text of the source code is left in the lexical analysis stage. The original text lexical structure is tested through the interface to obtain source code defects based on lexical analysis.

[0021] Optionally, step 3 specifically includes:

[0022] Simulate execution according to the source code execution mode, generate the program extension graph based on AST and control flow graph, record and update the value range and constraints of symbol values ​​and conditional expressions, and detect potential complex defects through constraint solving of path conditions.

[0023] Optionally, a ternary modeling approach is used to track the recording and update status of symbol values.

[0024] In summary, this application has the following beneficial technical effects:

[0025] This application is suitable for source code defect detection of QEMU component models, especially in large and complex projects, with better results than traditional source code detection. This method is based on projects developed on the QEMU virtualization platform, supports static analysis of programming languages ​​such as C, and can detect common problems such as memory management, improper pointer usage, and resource leaks. By combining detection with deep learning models, this application greatly improves the accuracy and efficiency of source code defect detection, reduces the false alarm rate, and helps improve the quality of QEMU component models. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0027] Figure 1 This is a flowchart of the intelligent detection method of QEMU component digital model for this application;

[0028] Figure 2 This is the basic architecture of the Transformer-based CBCD-LLM model in the embodiments of this application. DETAILED DESCRIPTION

[0029] The embodiments of the present application are described in detail below with reference to the accompanying drawings.

[0030] The following describes the embodiments of the present application through specific examples, and those skilled in the art can easily understand other advantages and effects of the present application from the contents disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. The present application can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present application. It should be noted that, in the absence of conflict, the features in the following embodiments and embodiments can be combined with each other. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without making creative work are within the scope of protection of this application.

[0031] It should be noted that various aspects of the embodiments within the scope of the appended claims are described below. It should be apparent that the aspects described herein can be embodied in a wide variety of forms, and any specific structure and / or function described herein is merely illustrative. Based on this application, it should be understood by those skilled in the art that an aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects described herein can be used to implement an apparatus and / or practice a method. In addition, other structures and / or functionalities other than one or more of the aspects described herein can be used to implement this apparatus and / or practice this method.

[0032] It should also be noted that the illustrations provided in the following embodiments are only schematic illustrations of the basic concept of the present application. The illustrations only show components related to the present application and are not drawn according to the number, shape and size of components in actual implementation. In actual implementation, the type, quantity and proportion of each component can be changed at will, and the component layout type may also be more complicated.

[0033] Additionally, in the following description, specific details are provided to provide a thorough understanding of the examples. However, one skilled in the art will appreciate that the aspects described may be practiced without these specific details.

[0034] The embodiment of the present application provides an intelligent detection method for the digital model of QEMU components.

[0035] like Figure 1 As shown, an intelligent detection method for digital models of QEMU components;

[0036] Starting from the input of the source code, after a series of analysis and detection, the source code defect information is finally output. After the source code is input into the system, it is first parsed by the compiler front-end in the compilation tool chain adaptation module to generate an abstract syntax tree AST and a control flow graph CFG. The AST reflects the structure and hierarchical relationship of the code, while the CFG describes the control flow of the program in different states, which is helpful for subsequent defect detection; based on the generation of AST and CFG, defect detection and confirmation are performed in sequence. The embodiment of the present application comprises a compilation tool chain adaptation module, a detection rule set configuration module, a source code defect detection module based on rule matching, a source code defect detection module based on symbolic execution, and a source code defect detection and confirmation module based on deep learning.

[0037] Specifically include:

[0038] Step 1: Obtain the source code of the QEMU component digital model; Step 1 specifically includes:

[0039] During the compilation process, the toolchain adapter module, based on the fact that the QEMU component digital model uses the Makefile compilation toolchain, collects build information by directly running the Makefile or simulating a build run. This information includes the list of source files to be analyzed, the source file compilation options, the header file search path, and key predefined macro information. This information is crucial for the analysis phase, enabling a complete and automated analysis of the entire QEMU component digital model project.

[0040] The source code to be tested is obtained by combining the source file list, the compilation options of the source file, the header file search path and the predefined macro key information.

[0041] The source code to be tested is replaced with the original code by predefined macros and header file inclusions according to the header file search path and predefined macro key information, and then a complete source code to be tested is formed. The complete source code to be tested is scanned and the source code file is converted into AST.

[0042] The detection rule set configuration module analyzes the characteristics of the digital models of QEMU components. Combining existing rule sets, a set of detection rules suitable for QEMU components is constructed. These detection rules include source code defect rule definitions, symbolic execution techniques, GJB-8114, MisraC2012, CWE, and custom rules. These rules cover common defect types such as memory management, type safety, pointer usage, coding standards, array overflow and underflow, integer overflow, improper memory buffer operation restrictions, double pointer freeing, null pointer dereference, use of freed resources, failure to free resources at the end of their lifecycle, failure to free dynamically allocated space, divide-by-zero errors, dead code, unsafe API calls, and floating-point loop variables.

[0043] There are four main methods for detecting source code defects: matching based on an abstract syntax tree, matching based on preprocessing, matching based on file unit statistics, and custom matching based on lexical analysis. The embodiments of this application specifically disclose a defect detection method based on abstract syntax tree matching.

[0044] Step 2: Based on the source code abstract syntax tree and according to the definition of source code defect rules, source code defects in the QEMU component digital model are matched. Step 2 is performed by the source code defect detection module based on rule matching, which specifically includes:

[0045] Use the abstract syntax tree to build a matching object corresponding to the source code. Combine the class implemented by the matching object with the source code defect rules to match and obtain the source code defects detected based on the abstract syntax tree:

[0046] Defect detection for abstract syntax tree matching consists of two main parts: the implementation of the matching mechanism and the implementation of the matching object. The matching mechanism is implemented by an abstract syntax tree matcher through a registration mechanism. The matching object implementation primarily includes the declaration class Decl, the statement class Stmt, the type class QualType, and the TypeLoc class. Abstract syntax tree-based detection currently favors rule matching. A drawback of this approach is that it only matches a single point on the abstract syntax tree, while some rules require reference to other relevant features of the entire file unit to make a judgment.

[0047] Preprocessor directives are an essential component of the C language. Preprocessor statements are processed by the preprocessor before the lexical analysis phase, so they cannot be analyzed based on the abstract syntax tree. While scanning the complete source code to be tested, when the #if and #endif preprocessor statements are encountered, the analysis engine calls the registerPPCallbacks class in the preprocessor. The registerPPCallbacks function adds overloaded functions for preprocessor directives during the preprocessing phase, thereby detecting source code defects based on preprocessor directives.

[0048] Based on the matching method of file unit statistics, two functions, onStartOfTranslationUnit and onEndOfTranslation-Unit, are defined. They are run when entering and ending a file unit respectively.

[0049] When analyzing the file unit in the source code, the onStartOfTranslationUnit function is used to initialize and allocate storage space when entering the file unit. Statistics are collected and written to the storage space when performing abstract syntax tree matching. When the file unit analysis ends, the onEndOfTranslationUnit function is called, and analysis is performed based on the content in the storage space to obtain source code defects detected based on file unit statistics.

[0050] While the above-mentioned rule-based detection system has achieved relatively complete rule-based detection, it still requires detection for many source code features that are difficult to abstract or have not yet been abstracted. Therefore, during the lexical analysis phase of scanning the complete source code to be tested, an interface is provided to obtain the original source code text. This interface is used to perform lexical detection on the original text to obtain source code defects based on lexical analysis. This allows detection of defects in source code features that are difficult to abstract or have not yet been abstracted.

[0051] Step 3: Generate an extension graph of the program based on the source code, and perform path dependency analysis on the source code using symbolic execution technology to detect potential source code defects that depend on the execution path.

[0052] Step 3 is performed by a source code defect detection module based on symbolic execution, specifically including:

[0053] This technology simulates execution according to the source code, generates an extended diagram of the program based on the AST and control flow graph, records and updates the ranges and constraints of symbolic values ​​and conditional expressions, and detects potential complex defects through constraint solving of path conditions. Symbolic execution technology enables deeper analysis of program execution paths, particularly in multi-branch paths, to identify potential logical vulnerabilities and security issues. Examples include array overflows and underflows, pointer double frees, and resources not being released at the end of their lifecycles.

[0054] In the embodiments of this application, ternary modeling is used to track the recording and update status of symbolic values, better representing the relationship between expressions, memory objects, and values. This unified and complete representation enables the symbolic execution engine to more realistically simulate the execution state of programs. For example, an expression is explained using a triple: Expression, Memory Object, and Value.

[0055] In programming languages, an expression is a textual representation of a variable name, operation, or action within a program. An expression can represent an object in memory during program execution. Such expressions are called l-value expressions and can be assigned or modified.

[0056] A memory object can be a variable, an array, an array element, a structure, a structure field, a dynamically allocated memory block, and so on. In static analysis, the concept of "region" is used to represent memory objects. A region is an abstract representation of a memory object, as a memory object always occupies a contiguous region in the address space. Furthermore, static analysis requires understanding not only the mapping between expressions and regions but also the structural, or hierarchical, relationships between regions. For example, the region of an array is composed of the regions of all its elements. However, for an array itself, each element is represented by a different region. Furthermore, because the region of an array element is subordinate to the region of the array, a parent-child relationship is established between regions: the parent region of an array element is the array region. The stack, heap, and static storage used in a program are also represented by three regions: the stack region, the heap region, and the static region. Thus, if an array is a local array, its parent region is the stack region. This not only represents the relationship between expressions and regions, but also the hierarchical relationship between regions, providing deeper support for symbolic execution engines.

[0057] A value is a value stored in memory. These values ​​are divided into two categories: those that describe memory addresses, called location values, and those that describe ordinary values, called non-location values. A location value is the starting address of a pointer. Depending on the type, the value of the stored object can be read. A non-location value, depending on the type, is the value of the expression.

[0058] Step 4 uses a deep learning model to detect the source code and obtain detection results. Based on the detection results, it is confirmed whether the source code defects in steps 2 and 3 are correct. Step 4 is performed using the deep learning-based source code defect detection and confirmation module.

[0059] After using static analysis technology for defect detection, a large number of potential defect reports are often generated, but some of them may be "false positives". This application uses a deep learning model to confirm the defects detected by the rule matching and symbolic execution detection modules to further reduce the false positive rate.

[0060] In this application, a large-scale model for source code defect detection (Code-Bugs-Confirmation / Detection–Large Language Model, CBCD-LLM) is designed. This model adopts the basic architecture of encoder-decoder, with source code content as input and source code defect confirmation or detection information as output.

[0061] Before the model training phase, a high-quality dataset is first constructed. Data sources include public code repositories (such as GitHub), internal enterprise code repositories, open source projects, the Juliet test set, and QEMU-related test code. Data screening, labeling, and augmentation are then performed, and the training dataset is constructed. The labeled data is divided into training, validation, and test sets according to a certain ratio. For a complete code segment, defects often only occur in a few lines, while the remaining large amount of code is correct. Therefore, for defective code samples, their corresponding weights need to be adjusted to avoid model bias. In addition, recursive feature elimination (RFE) and an improved lion group optimization algorithm (ILSO-BP) are combined to effectively improve detection accuracy. Training and enhancement are then performed based on the dataset. Through training on a large amount of code data, the CBCD-LLM model can detect and confirm more complex code patterns and potential security issues.

[0062] This model uses the Transformer architecture model as the basic architecture, and the specific implementation is as shown in the attached Figure 2 shown.

[0063] For the input embedding layer, the input of the encoder and decoder first passes through the embedding layer to convert the code into a vector representation, which can capture the semantic relationship between the context, as well as the complex patterns and potential grammatical rules in the code.

[0064] The multi-head attention layer mechanism enables each token to pay attention to other tokens in the input sequence, thereby better understanding the context. Multi-head attention allows the model to focus on different parts on multiple different "heads", thereby improving the model's ability to capture multi-faceted information.

[0065] The masked multi-head attention layer ensures that the model can only see the previous tokens when predicting the next token. This mechanism ensures that the decoder does not "peek" at future tokens, making the generation process autoregressive.

[0066] Residual connections and layer normalization make the model more stable and accelerate training. Residual connections allow information to bypass certain layers, avoiding the gradient vanishing problem; layer normalization allows the model to converge faster.

[0067] The feedforward neural network layer provides nonlinear transformation for the output of each position, making the model more expressive. The feedforward layer consists of two fully connected layers with an activation function in between.

[0068] For the linear layer and SoftMax activation function of the decoder, at the end of the decoder, after being processed by the previous layers, the generated output undergoes linear transformation and SoftMax activation function to generate the probability distribution of each token on the Token table. Based on this probability distribution, the next token is selected and the output sequence is gradually generated.

[0069] Both the encoder and decoder are composed of multiple identical stacked layers (the part represented by Nx), usually containing 6 to 12 layers. As the number of layers increases, the expressive power of the model increases.

[0070] The output embedding converts the model's internal representation into natural language output. It bridges the gap between the model's semantic space and the actual vocabulary space, enabling the model to output grammatically and semantically coherent text through the decoder.

[0071] This application has experimentally demonstrated that, for QEMU component model source code defects, using source code defect detection based on rule matching engines and symbolic execution engines, and confirming them through the deep learning model CBCD-LLM, the accuracy rate is improved by 13.5% compared to the detection results of TestBed. At the same time, by using the deep learning model CBCD-LLM to directly detect defects in the source code, and merging the detected defects with the confirmed defects, the recall rate of this application for QEMU component model detection is improved by 7.3% compared to TestBed.

[0072] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in the present application should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

Claims

1. An intelligent detection method for QEMU component digital models, characterized in that: include: Step 1: Get the source code of the QEMU component digital model; Step 2: Based on the abstract syntax tree of the source code and according to the definition of source code defect rules, match the source code defects in the QEMU component digital model; Step 3: Generate an extension graph of the program based on the source code, and perform path dependency analysis on the source code using symbolic execution technology to detect potential source code defects that depend on the execution path. Step 4: Use the deep learning model to detect the source code and obtain the detection results. Based on the detection results, confirm whether the source code defects in steps 2 and 3 are correct. During the compilation process, build information is collected by directly running the Makefile or simulating the build, obtaining the list of source files that need to be analyzed, the compilation options of the source files, the header file search path, and the key information of predefined macros; Get the source code to be tested by combining the source file list, source file compilation options, header file search path and predefined macro key information; The source code to be tested replaces the predefined macros and header files with the original code according to the header file search path and predefined macro key information to form a complete source code to be tested, scans the complete source code to be tested, and converts the source code file into an abstract syntax tree AST; The step 2 specifically includes: Use the abstract syntax tree to build a matching object corresponding to the source code. Combine the class implemented by the matching object with the source code defect rules to match and obtain the source code defects detected based on the abstract syntax tree: During the scanning of the complete source code to be tested, when the #if and #endif preprocessing statements are scanned, the registered PPCallbacks class in the preprocessor of the analysis engine is called, and the overloaded function for the preprocessing instructions added in the preprocessing stage by the registerPPCallbacks function is used to detect source code defects based on preprocessing instructions; when analyzing the file units in the source code, the onStartOfTranslationUnit function is used to initialize and allocate storage space when entering the file unit, and statistics are collected and written to the storage space when performing abstract syntax tree matching. When the file unit analysis ends, the onEndOfTranslationUnit function is called, and analysis is performed based on the content in the storage space to obtain source code defects detected based on file unit statistics; During the scanning process of the complete source code to be tested, an interface for obtaining the original text of the source code is left in the lexical analysis stage. The original text lexical structure is tested through the interface to obtain source code defects based on lexical analysis.

2. The intelligent detection method for QEMU component digital models according to claim 1, characterized in that: The step 1 further comprises: The characteristics of the digital models of QEMU components are analyzed, and a set of detection rules suitable for QEMU components is organized and constructed by combining some existing rule sets. The detection rules include source code defect rule definition, symbolic execution technology, GJB-8114, Misra C 2012, CWE and custom rules.

3. The intelligent detection method for QEMU component digital models according to claim 1, characterized in that: The step 3 specifically includes: Simulate execution according to the source code execution mode, generate the program extension graph based on AST and control flow graph, record and update the value range and constraints of symbol values ​​and conditional expressions, and detect potential complex defects through constraint solving of path conditions.

4. The intelligent detection method for QEMU component digital models according to claim 3, characterized in that: The record and update status of symbol values ​​are tracked using ternary modeling.

Images