Concurrent vulnerability detection method based on code concurrency attribute graph

Abstract

The invention provides a concurrent vulnerability detection method based on a code concurrent attribute graph. The method comprises the following steps: adopting a vulnerability detection tool CONCODEQL; the method comprises the following steps: S1, initializing a code attribute graph and identifying key nodes according to source codes; s2, traversing the initial graph to construct a concurrency relationship; and S3, detecting concurrent violation according to the designed domain specific language. According to the method, by introducing the CCPG, various relations and features in the concurrent program source code can be comprehensively expressed, and the defect that an existing static code detection method based on structured representation is difficult to recognize complex concurrent vulnerabilities is overcome. And on the basis of a CCPG domain-specific language, detection for different types of concurrent vulnerabilities is supported, and the expansibility of the tool is improved. By combining the capability of the CCPG, the false report rate and the missing report rate of a traditional data race detection method are effectively reduced, and the detection capability of complex concurrency problems is enhanced.

Description

Technical Field

[0001] The present invention provides a concurrent vulnerability detection method based on a code concurrent property graph, belonging to the technical field of computer software security. Background Art

[0002] In order to improve the performance of software, more and more concurrent programming models are incorporated into modern software applications. These concurrent programs can make full use of multi-core CPUs to accelerate computing and significantly improve execution speed. However, the interleaved execution of threads in concurrent programs introduces considerable uncertainty, which may lead to many vulnerabilities unique to this environment, and this uncertainty makes these vulnerabilities difficult to detect and fix. Against the above background, a lot of research work is devoted to detecting various vulnerabilities in concurrent programs. Researchers have explored detecting data races, synchronization errors (such as deadlocks and unreleased locks), memory-related vulnerabilities in concurrent scenarios (such as double free and use-after-free vulnerabilities), etc. In general, the detection methods for different types of vulnerabilities vary greatly. Data race detection mainly focuses on unsafe access to shared memory, while synchronization error detection emphasizes the correctness of synchronization logic.

[0003] From a technical perspective, many researchers have focused on dynamic analysis methods, which combine testing with formal reasoning to report concurrency errors by tracking all possible valid reorderings under different program inputs. Due to the limitation of exhaustive computational complexity, many partial order-based techniques have emerged. Currently, a lot of work is devoted to constructing efficient and computable weak partial orders. Although these methods can accurately detect concurrency bugs, they all have the natural defects of dynamic analysis: significant performance overhead and limited coverage.

[0004] Relatively speaking, there are relatively few static analysis tools that can be used to detect concurrency errors. Notable tools in this field include RacerD and Coderrect. Both tools focus on data competition and detect it by analyzing the access pattern of shared variables. Compared with sequential program analysis, the main challenge is to analyze memory access in concurrent scenarios and determine the parallel relationship between statements. In terms of memory access analysis, traditional methods use data flow analysis to capture the semantics within and between threads. Later, in order to improve accuracy and reduce overhead, memory access analysis using pointer analysis became the mainstream. Most of these methods are based on value stream graphs. In terms of parallel relationship analysis, they mainly include lock set-based work and static happen-before relationship work. Lock set-based methods, such as Locksmith, detect concurrency vulnerabilities by determining whether all accesses to shared locations are always protected by locks. Static happen-before relationships represent programs as abstract graphs of threads to determine the parallel relationship between nodes. The most advanced methods usually combine these two techniques to more accurately determine the parallel relationship between statements.

[0005] Subsequently, some general-purpose static program analysis tools have emerged that support the detection of concurrent errors, such as CodeQL and Joern. These tools first convert the source code into structured representations (i.e., relational data or graphs), save them to a database, and then query the database using a domain-specific language. This mechanism allows the definition of complex error detection patterns that can be queried in the database.

[0006] CodeQL is an advanced static code analysis tool launched by GitHub, which is widely used for security checks and vulnerability research. Its core concept is to treat code as data. By converting the code base into a queryable database, developers can write query statements to detect security vulnerabilities, potential bugs, and other quality issues in the code. Although CodeQL performs well in detecting general security vulnerabilities and logical defects, it is not mature in detecting concurrency errors (such as race conditions and deadlocks). The fundamental reason is that the code property graph on which CodeQL relies cannot fully express concurrency relationships. The core data representation of the code property graph mainly focuses on the grammatical structure and control / data flow of the code, and cannot directly model threads, locks, and their interactions. The detection of concurrency errors usually requires in-depth modeling of the following issues:

[0007] Synchronization and communication between threads: such as acquisition and release of locks, use of semaphores, etc.

[0008] Race condition: Multiple threads access shared resources at the same time and the order of access affects the program results.

[0009] Deadlock: Different threads enter a waiting state for each other due to resource competition.

[0010] Since the code property graph lacks an intuitive representation of the above concurrency semantics, CodeQL's analytical capabilities are limited in this type of problem. Although CodeQL's functionality can be extended with additional logic and rules, its native capabilities are not optimized for concurrency issues. This means that CodeQL has a weak ability to detect concurrency errors, with low recall and precision.

[0011] Coderrect is a static analysis tool designed for concurrent programs, aiming to help developers identify concurrency issues in code, especially data contention. It supports mainstream concurrent programming interfaces such as OpenMP, Pthreads, and C++ standard thread libraries, and uses static analysis technology to quickly discover and solve potential problems during the development phase.

[0012] Although Coderrect has a strong ability to detect data races, its limitation is that it only focuses on this type of problem. Coderrect does not provide support for other types of concurrency errors (such as deadlock, livelock, race conditions) and concurrency-related vulnerabilities. This means that it cannot cover all potential risks in concurrent programming, and developers may need to combine other tools for a more comprehensive analysis. Summary of the invention

[0013] The present invention is aimed at the detection of concurrent programs and aims to propose a concurrency vulnerability detection technology based on code concurrency property graph. The goal is to solve the limitations of existing work such as weak scalability and low accuracy, and to achieve a more general and mature concurrency vulnerability detection tool, thereby improving the security of the software.

[0014] Specifically, the main issues to be addressed include:

[0015] (1) Existing static code detection methods based on structured representation lack the representation of concurrent program features, making it difficult to identify complex concurrent vulnerabilities. The present invention proposes CCPG (Code Concurrency Property Graph), which can effectively express various relationships and features in the source code of concurrent programs;

[0016] (2) Existing concurrent vulnerability detection tools have poor scalability and can only target specific vulnerabilities or certain vulnerabilities. The present invention designs a domain-specific language for different types of vulnerability detection based on CCPG;

[0017] (3) Traditional data competition detection methods lack a comprehensive analysis of various grammatical relationships, memory access patterns, and concurrency mechanisms in the source code, which leads to false positives and negatives. The present invention designs a domain-specific language based on CCPG that is specifically used to define complex concurrency rules, thereby enhancing the recognition of subtle concurrency issues that traditional tools may overlook.

[0018] The complete technical solution provided by the present invention is:

[0019] A concurrency vulnerability detection method based on code concurrency property graph uses vulnerability detection tool CONCODEQL. It includes the following processes: initializing code property graph and identifying key nodes according to source code, traversing the initial graph to build concurrency relations, and detecting concurrency violations according to the designed domain-specific language.

[0020] S1. Initialize the code property graph and identify key nodes based on the source code. Based on the source code to be tested, on the basis of the traditional code property graph (CPG) and value stream graph (VFG), initialize the code concurrency property graph CCPG and identify the key nodes in the concurrent program in the graph.

[0021] S2. Traverse the initial graph to build concurrent relationships. Traverse the initialized graph to build context information. Based on the context, perform flow-sensitive hapeens-before analysis, inter-procedural lock set analysis, and enhanced concurrent pointer analysis to build concurrent relationships between nodes in the graph.

[0022] S3. Detect concurrency violations based on the designed domain-specific language. A domain-specific language query API is designed for different types of concurrency vulnerabilities. Concurrency violation detection is performed by querying in the graph. Domain-specific language queries are also designed for some complex judgments. Finally, the detected concurrency vulnerabilities are printed into a report.

[0023] The details of the above steps are described in detail below.

[0024] S1, initialize the code attribute graph and identify key nodes according to the source code;

[0025] CONCODEQL first generates a code property graph and a value stream graph based on the source code, identifies concurrency-related APIs from the code property graph, and defines a code concurrency property graph CCPG for concurrent programs based on the information obtained from the value stream.

[0026] The nodes of the code concurrency property graph include the following three types:

[0027] 1. Memory access node: This type of node is used to represent the access to memory in the code;

[0028] 2. Concurrent behavior nodes: This type of node corresponds to the concurrent behavior-related API in the source code, and is further divided into two subcategories: thread organization nodes, including FORK nodes, JOIN nodes, DETACH nodes, and EXIT nodes; and synchronization logic nodes, including lock acquisition nodes (ACQUIRE) and lock release nodes (RELEASE).

[0029] 3. Other nodes: nodes that represent the basic running logic of the program.

[0030] The edges of the code concurrency attribute graph are divided into two categories: conventional code attribute graph edges (abstract syntax tree edges, control flow edges, and dependency edges) and concurrency relationship edges. The latter can be divided into two categories:

[0031] 1. Thread-Lifecycle edges: including the edge from the FORK node to the corresponding thread entry, and the edge from the thread exit to the JOIN node.

[0032] May-Happens-Parallel Edges: Connect nodes from different threads that may occur in parallel. For simplicity, CONCODEQL only connects nodes that access the same memory location.

[0033] S2, traverse the initial graph to build concurrent relationships;

[0034] Perform thread-aware and flow-sensitive analysis.

[0035] First, the thread-aware context is defined as: for a given node, each path from the main entrance to the node includes all ancestor threads and the current thread. Therefore, the thread-aware context along a specific path is represented as c = [n1, n2, ..., n m ], where each element represents a concurrent behavior node, a node n i All thread-aware contexts are represented as a two-dimensional matrix k represents the number of possible paths from the main entrance to the current node.

[0036] Next, we conduct flow-sensitive happens-before analysis, that is, construct happens-before edges based on thread-aware context. The main purpose of the analysis is to infer the relationship between two nodes n i and n j For a given node n i , first for each of its threads to perceive the context Constructing a fork set The fork set is defined as Right now It is only composed of FORK nodes whose corresponding threads in the current context have not yet joined. i and n j The happens-before relationship of the two nodes n is checked by CONCODEQL to see if their fork sets overlap with each other. Overlapping fork sets means that the two nodes n i and n j can occur in parallel. Formally, the present invention uses the following formula to determine n i and n j HP relationship:

[0037]

[0038] Then, we perform inter-procedural lock set analysis. Analyzing only the happens-before relationship is not enough to determine whether two nodes can be executed concurrently, because nodes can be protected by locks. Given two nodes n i and n j The main purpose of lock set analysis is to infer n i and n j Are they protected by the same lock? For this purpose, given a node ni , CONCODEQL first builds a lock set for each of its thread-aware contexts Define the lock set as express It consists only of lock acquisition nodes whose corresponding locks in the current context have not been released. CONCODEQL then determines n by checking whether the lock sets overlap each other. i and n j Whether it is protected by the same lock. Formally, the following formula is used to determine n i and n j PSL relationship:

[0039]

[0040] Then perform on-demand pointer analysis for concurrency enhancement:

[0041] (1) Global variables: By analyzing CCPG and value stream graphs, we designed an accurate analysis of global variables. First, we identified all global variable declarations by traversing CCPG to obtain a set of global variables. Then, we reconstructed the connection between global variables and local variables in VFG, and determined the global variable aliases through flow-sensitive pointer analysis.

[0042] (2) Structure: For the access node of structure s, the specific attributes of the node access are simply obtained through CPG using regular expression judgment. CONCODEQL analyzes CCPG and VFG at the same time and adjusts the structure representation to specific attributes in pointer analysis.

[0043] Concurrency analysis feature algorithm, that is, how to implement thread-aware flow-sensitive analysis. The algorithm first needs to traverse the initial CCPG and build a thread-aware context for each node. Specifically, CONCODEQL first obtains all main entry nodes from CCPG and initializes their contexts to empty. In the main loop, if the current node with the current context is visited, CONCODEQL will terminate the loop directly. Otherwise, CONCODEQL will traverse CCPG along the thread life cycle edges and control flow edges. If the current node n is a FORK node that creates a new thread, the context of the entry node n′ of the new thread will be initialized to each context previously added to node n, and a new thread t will be created. newIf the current node n is not a FORK node, it simply traverses along the control flow edges and propagates the context of the current node to the subsequent nodes. The context constructed for each node is then used for subsequent happens-before relationships and lock set analysis. Then based on the context of each node, CONCODEQL traverses any pair of threads and checks whether their memory access nodes can occur in parallel. Specifically, if two nodes n i and n j If both of them meet the following conditions: 1) access the same memory location; 2) may occur in parallel; and 3) are not protected by the same lock, CONCODEQL will i , n j ) add a HP edge (May-Happens-ParallelEdge) between them. Finally, the algorithm generates an updated graph CCPG.

[0044] S3, concurrent violations according to the designed detection;

[0045] Concurrency errors are classified into data races, deadlocks, atomicity errors, and order violations.

[0046] A domain specific language is defined as a grammar L = {V T ,V N , P, S}, where V T is a set of terminal symbols, V N It is a set of non-terminal symbols. The set of production rules P constitutes the main structural unit of the grammar. Each production rule p i Expressed as α::=β, it describes the method of combining elements in the terminal symbol set and the non-terminal symbol set into a string, and S is the starting symbol.

[0047] The DSL is designed by using and extending the query statements used in the CodeQL DSL. In this structure, <query>It represents the starting symbol S in the definition and serves as the entry point for the domain-specific language;<var_delcs> Indicates variable declaration, including basic variable types and built-in variable types<built-in type> ; <condition>Define constraints in queries; <returns>Specifies the value that the query returns.

[0048] The language's specificity to the concurrency domain is reflected in the structure<built-in type> and<concurrent_relation_condition> middle.<concurrent_relation_condition> Include <access_condition>、<hb_relationship> and<lock_condition> , respectively handle thread-aware pointer analysis, happens-before relations, and lock set analysis. Specifically, the lock analysis includes the IS PROTECTED BY and IS AUTOMATICALLY PROTECTED BY methods, the former determines whether two variables are protected by the same lock, and the latter checks whether operations are in the same critical section to ensure atomicity. These syntactic features enhance the ability of domain-specific languages ​​to support the detection of a large number of concurrency errors.

[0049] The present invention proposes a concurrency vulnerability detection technology based on code concurrency property graph (CCPG), which has significant beneficial effects. First, by introducing CCPG, the present invention can fully express various relationships and features in the source code of concurrent programs, overcoming the shortcomings of the existing static code detection method based on structured representation that is difficult to identify complex concurrency vulnerabilities. Secondly, the present invention designs a domain-specific language based on CCPG, which supports the detection of different types of concurrency vulnerabilities, greatly improves the scalability of the tool, and enables it to adapt to a wider range of application scenarios. Finally, by combining the capabilities of CCPG, the domain-specific language of the present invention can comprehensively analyze the grammatical relationships, memory access patterns and concurrency mechanisms in the source code, thereby effectively reducing the false positive and false negative rates of traditional data competition detection methods, and enhancing the detection capabilities of complex concurrency problems. In general, the present invention provides a technical basis for the development of more general and mature concurrency vulnerability detection tools, significantly improving the security and reliability of software. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] Figure 1 It is the overall workflow diagram of CONCODEQL of the present invention;

[0051] Figure 2 Example of thread-aware analysis for an embodiment

[0052] Figure 3 A flowchart of a thread-aware context building method of an embodiment;

[0053] Figure 4 The main framework diagram of the domain specific language (Domain Specific Language) of the embodiment

[0054] Figure 5 Screenshot of concurrency-specific components of a domain specific language for an embodiment;

[0055] Figure 6 A screenshot of a query example for data race detection in an embodiment. DETAILED DESCRIPTION

[0056] The present invention provides a concurrent vulnerability detection method based on a code concurrent property graph, using a vulnerability detection tool CONCODEQL. The core workflow framework of the invention is as follows: Figure 1 As shown, CONCODEQL mainly includes three processes: initializing the code property graph and identifying key nodes based on the source code, traversing the initial graph to build concurrent relationships, and detecting concurrency violations based on the designed domain-specific language.

[0057] S1. Initialize the code property graph and identify key nodes based on the source code. Based on the source code to be tested, on the basis of the traditional code property graph (CPG) and value stream graph (VFG), initialize the code concurrency property graph CCPG and identify the key nodes in the concurrent program in the graph.

[0058] S2. Traverse the initial graph to build concurrent relationships. Traverse the initialized graph to build context information. Based on the context, perform flow-sensitive hapeens-before analysis, inter-procedural lock set analysis, and enhanced concurrent pointer analysis to build concurrent relationships between nodes in the graph.

[0059] S3. Detect concurrency violations based on the designed domain-specific language. A domain-specific language query API is designed for different types of concurrency vulnerabilities. Concurrency violation detection is performed by querying in the graph. Domain-specific language queries are also designed for some complex judgments. Finally, the detected concurrency vulnerabilities are printed into a report.

[0060] The details of the above steps are described in detail below.

[0061] S1. Initialize the code attribute graph and identify key nodes based on the source code;

[0062] CONCODEQL first generates a code property graph and a value stream graph based on the source code, identifies concurrency-related APIs from the code property graph, and defines a code concurrency property graph (CCPG) for concurrent programs based on the information obtained from the value stream.

[0063] The nodes of the code concurrency property graph include the following three types:

[0064] 4. Memory access nodes: These nodes are used to represent memory access in the code and may be used by concurrent mechanisms for thread synchronization, communication, scheduling and other operations. These nodes correspond to four behaviors in the source code: address request (ALLOC), address release (FREE), variable read (READ), and variable write (WRITE).

[0065] 5. Concurrent behavior nodes: This type of node is the most important type of node in CCPG and is one of the main differences from conventional CPG. This type of node corresponds to concurrent behavior-related APIs in the source code, which are further divided into two subcategories: thread organization nodes, including FORK nodes, JOIN nodes, DETACH nodes, and EXIT nodes; synchronization logic nodes, including lock acquisition nodes (ACQUIRE) and lock release nodes (RELEASE).

[0066] 6. Other nodes: nodes that represent the basic running logic of the program, such as assignment nodes, branch nodes, call nodes, function nodes, and return nodes.

[0067] The edges of the code concurrency attribute graph are divided into two categories: conventional code attribute graph edges (abstract syntax tree edges, control flow edges, and dependency edges) and concurrency relationship edges. The latter can be divided into two categories:

[0068] 2. Thread-Lifecycle edges: These edges are crucial for establishing execution order in concurrent operations, including the edge from the FORK node to the corresponding thread entry, and the edge from the thread exit to the JOIN node.

[0069] May-Happens-Parallel Edges: Connect nodes from different threads that may occur in parallel. For simplicity, CONCODEQL only connects nodes that access the same memory location.

[0070] S2, traverse the initial graph to build concurrent relationships;

[0071] In order to construct the possible parallel edges, the present invention performs thread-aware and flow-sensitive analysis. Flow-sensitive analysis is a technique in static program analysis that considers the execution order of statements or instructions in a program. In addition, thread-aware flow-sensitive analysis further considers not only flow but also the concurrency aspects of the program, such as thread synchronization, shared resources, and potential race conditions.

[0072] Thread-aware analysis has been applied to pointer analysis of concurrent programs by some works, but the method of applying thread-aware flow-sensitive analysis to statically determine concurrency relations has not been studied.

[0073] The present invention first defines the thread-aware context as: for a given node, each path from the main entrance to the node includes all ancestor threads and the current thread. Therefore, the thread-aware context along a specific path can be expressed as c = [n1, n2, ..., n m ], where each element represents a concurrent behavior node, a node n i All thread-aware contexts can be represented as a two-dimensional matrix k represents the number of possible paths from the main entrance to the current node. Figure 2 A simplified example of a concurrent program is given. In this example, x is a global variable. The main function creates two threads t1 and t2. Each thread contains a write(x) statement. The thread-aware context of t1:write(x) is [fork(t1, call), acquire_lock(1)], and the thread-aware context of t2:write(x) is [fork(t1, call), join(t1), fork(t2, call), acquire_lock(1)].

[0074] Next, we conduct flow-sensitive happens-before analysis, that is, construct happens-before edges based on thread-aware context. The main purpose of the analysis is to infer the relationship between two nodes n i and n j For a given node n i The present invention first perceives the context for each of its threads Constructing a fork set The fork set is defined as Right now It is only composed of FORK nodes whose corresponding threads in the current context have not yet joined. i and n j The happens-before relationship of the two nodes n is checked by CONCODEQL to see if their fork sets overlap with each other (there is at least one common element). Overlapping fork sets means that the two nodes n i and n j can occur in parallel. Formally, the present invention uses the following formula to determine n i and n j The hp (happen in parallel) relationship is:

[0075]

[0076] Then we perform inter-procedural lock set analysis. Analyzing only the happens-before relationship is not enough to determine whether two nodes can be executed concurrently, because nodes can be protected by locks. Given two nodes n i and n j The main purpose of lock set analysis is to infer n i and n j Are they protected by the same lock? For this purpose, given a node n i , CONCODEQL first builds a lock set for each of its thread-aware contexts Define the lock set as express It consists only of lock acquisition nodes whose corresponding locks in the current context have not been released. CONCODEQL then determines n by checking whether the lock sets overlap each other. i and n j Whether it is protected by the same lock. Formally, the present invention uses the following formula to determine n i and n j PSL (protected by the same lock) relationship:

[0077]

[0078] Then, we conduct on-demand pointer analysis for concurrency enhancement, which is a key aspect of static analysis. Existing methods aim to address the unique challenges brought by concurrent environments, especially a flow-sensitive multi-threaded pointer analysis method based on the sparse value stream (SVF) framework. Although it has made considerable progress, we observe that the existing methods have some limitations in handling global variables and structures, so we make targeted improvements to them:

[0079] (1) Global variables: Global variables are an important part of shared memory in concurrent programs. However, when using advanced pointer analysis tools such as SVF-Tool to analyze more complex programs, errors often occur when analyzing global variables. This problem may be due to LLVM's inherent insensitivity to global variables. In order to solve this problem, the present invention designs an accurate analysis of global variables by analyzing CCPG and value stream graphs. First, the present invention identifies all global variable declarations by traversing CCPG, thereby obtaining a set of global variables. Then the present invention reconstructs the connection between global variables and local variables in VFG, and determines the global variable aliases through flow-sensitive pointer analysis. This method uses the information provided by CPG to significantly enhance the analysis capability of global variables.

[0080] (2) Structure: It is well known that pointer analysis has poor support for accessing structure attributes. Existing methods can accurately analyze access to structure variable pointers, but they have difficulty determining which specific attribute of the structure is being accessed. This problem can be effectively solved using CPG. For access nodes of structure s, the present invention can use some regular expressions to simply obtain the specific attributes accessed by the node through CPG, such as s->a or sb, which allows the present invention to distinguish between pointers pointing to s and pointers pointing to s->a. Therefore, similar to the method for processing global variables, CONCODEQL analyzes CCPG and VFG simultaneously, and adjusts the structure representation to specific attributes in pointer analysis. This seemingly small adjustment helps the present invention significantly improve the accuracy of pointer analysis.

[0081] Finally, the overall concurrent analysis feature algorithm of the present invention, that is, how to implement thread-aware flow-sensitive analysis, is described. The algorithm first needs to traverse the initial CCPG and build a thread-aware context for each node, such as Figure 3 As shown. Specifically, CONCODEQL first obtains all main entry nodes from CCPG and initializes their contexts to empty. In the main loop, if the current node with the current context is visited (nodes with different contexts may be visited multiple times), CONCODEQL will terminate the loop directly. Otherwise, CONCODEQL will traverse CCPG along the thread lifecycle edges and control flow edges. If the current node n is a FORK node that creates a new thread, the context of the entry node n′ of the new thread will be initialized to each context previously added to node n, and a new thread t will be created. new If the current node n is not a FORK node, it simply traverses along the control flow edges and propagates the context of the current node to the subsequent nodes. The context constructed for each node is then used for subsequent happens-before relationships and lock set analysis. Then based on the context of each node, CONCODEQL traverses any pair of threads and checks whether their memory access nodes can occur in parallel. Specifically, if two nodes n i and n j If both of them meet the following conditions: 1) access the same memory location; 2) may occur in parallel; and 3) are not protected by the same lock, CONCODEQL will i , n j ) add a HP edge (May-Happens-ParallelEdge) between them. Finally, the algorithm generates an updated graph CCPG.

[0082] S3, concurrent violations according to the designed detection;

[0083] Concurrency errors are roughly divided into data races, deadlocks, atomicity errors, and order violations. While there are many tools for detecting data races and deadlocks, there is less work on addressing atomicity and order violations due to the complex relationships and rules between APIs, which usually requires a lot of pattern mining or document understanding. Domain-specific languages ​​can effectively address these challenges, allowing users to flexibly define the relationship between atomic operations and APIs, thereby facilitating the effective detection of atomicity and order errors. This paper defines a domain-specific language to provide a formal description for queries on CCPG, aiming to cover all types of concurrency errors.

[0084] A domain specific language is defined as a grammar L = {V T ,V N , P, S}, where V T is a set of terminal symbols, V N It is a set of non-terminal symbols. The set of production rules P constitutes the main structural unit of the grammar. Each production rule p i Expressed as a::=β, it describes the method of combining elements in the terminal symbol set and the non-terminal symbol set into a string, and S is the starting symbol.

[0085] The main architectures of domain-specific languages ​​are Figure 4 The DSL is designed by using and extending the query statements used in the CodeQL DSL. In this structure, <query>It represents the starting symbol S in the definition and serves as the entry point for the domain-specific language;<var_delcs> Indicates variable declaration, including basic variable types and built-in variable types <built-intype> ； <condition>Define constraints in queries; <returns>Specifies the value that the query returns.

[0086] The language's specificity to the concurrency domain is reflected in the structure <built-intype>and<concurrent_relation_condition> middle. Figure 5 The designs of these concurrency-specific components are presented.<concurrent_relation_condition> Include<access_condition> ,<hb_relationship> and<lock_condition> , respectively handling the thread-aware pointer analysis, happens-before relations, and lock set analysis mentioned above. Specifically, the lock analysis includes the IS_PROTECTED_BY and IS_AUTOMATICALLY_PROTECTED_BY methods. The former determines whether two variables are protected by the same lock, and the latter checks whether the operation is in the same critical section to ensure atomicity. These syntactic features enhance the ability of domain-specific languages ​​to support the detection of a large number of concurrency errors.

[0087] The query statement for data competition detection is as follows Figure 6 As shown, in this example, MEM_ACCESS, CONTEXT and LOCK are built-in classes, MEM_ACCESS corresponds to a memory access node, and CONTEXT and LOCK represent the results of thread-sensitive context analysis and lock set analysis, respectively. The ALIAS operation is used to determine whether two memory access nodes are pointer aliases in the context. In addition, in order to be consistent with the definition of data competition, the present invention adds a condition that the memory access nodes cannot be of READ type at the same time. In addition, the use of HAPPENS_BEFORE and PROTECTED_BY can ensure that the two memory access nodes can be executed concurrently, that is, they will not be effectively protected by the lock.

[0088] The present invention uses Joern 1.6 version as a tool when generating CPG. This tool for generating CPG can be replaced with other versions or other tools according to actual needs.

[0089] The present invention uses SVF-Tool as a pointer analysis tool, and this pointer analysis tool can be replaced with other versions or other tools according to actual needs. < / returns> < / condition> < / built-intype> < / query> < / returns> < / condition> < / query>

Claims

1. A concurrency vulnerability detection method based on code concurrency attribute graph, characterized in that: Use the vulnerability detection tool CONCODEQL; include The following process: S1. Initialize the code property graph and identify key nodes according to the source code; Based on the source code to be tested, on the basis of the traditional code property graph CPG and value stream graph VFG, initialize the code concurrency property graph CCPG and identify the key nodes in the concurrent program in the graph; S2, traverse the initial graph to build concurrent relationships; Traverse the initialized graph, build context information, and perform flow-sensitive hapeens-before analysis, inter-procedural lock set analysis, and enhanced concurrent pointer analysis based on the context to build the concurrent relationship of nodes in the graph; S3. Detect concurrency violations based on the designed domain-specific language. Design a domain-specific language query API for different types of concurrency vulnerabilities, perform queries in the graph to detect concurrency violations, and finally print the detected concurrency vulnerabilities into a report.

2. According to claim 1, a concurrency vulnerability detection method based on code concurrency attribute graph is characterized in that: The specific method of S1 is: CONCODEQL first generates a code property graph and a value stream graph based on the source code, identifies concurrency-related APIs from the code property graph, and defines a code concurrency property graph CCPG for concurrent programs based on the information obtained from the value stream. The nodes of the code concurrency property graph include the following three types: (1) Memory access nodes: These nodes are used to represent memory access in the code; (2) Concurrent behavior nodes: These nodes correspond to concurrent behavior-related APIs in the source code and are further divided into two subcategories: thread organization nodes, including FORK nodes, JOIN nodes, DETACH nodes, and EXIT nodes; and synchronization logic nodes, including lock acquisition nodes ACQUIRE and lock release nodes RELEASE; (3) Other nodes: nodes that represent the basic operation logic of the program; The edges of the code concurrency attribute graph are divided into two categories: conventional code attribute graph edges (abstract syntax tree edges, control flow edges, and dependency edges) and concurrency relationship edges. The latter can be divided into two categories: (1) Thread lifecycle edges: including the edge from the FORK node to the corresponding thread entry, and the edge from the thread exit to the JOIN node; (2) Edges that may occur in parallel: Connect nodes from different threads that may occur in parallel. For simplicity, CONCODEQL only connects nodes that access the same memory location.

3. According to claim 1, a concurrency vulnerability detection method based on code concurrency attribute graph is characterized in that: The specific method of S2 is: perform thread-aware and flow-sensitive analysis; Execution thread awareness: First, the thread-aware context is defined as: for a given node, each path from the main entrance to the node includes all ancestor threads and the current thread; therefore, the thread-aware context along a specific path is represented as c = [n1, n2, ..., n m ], where each element represents a concurrent behavior node, a node n i All thread-aware contexts are represented as a two-dimensional matrix k represents the number of possible paths from the main entrance to the current node; Next, we conduct flow-sensitive happens-before analysis, that is, construct happens-before edges based on thread-aware context. The main purpose of the analysis is to infer the relationship between two nodes n i and n j The execution order between them; for a given node n i , first for each of its threads to perceive the context Constructing a fork set The fork set is defined as Right now It is composed only of the FORK nodes whose corresponding threads in the current context have not yet joined; in order to analyze n i and n j The happens-before relationship of the two nodes n is checked by CONCODEQL to see if their fork sets overlap with each other. Overlapping fork sets means that the two nodes n i and n j can occur in parallel; use the following formula to determine n i and n j HP relationship: Then, we perform inter-procedural lock set analysis. Analyzing only the happens-before relationship is not enough to determine whether two nodes can be executed concurrently, because nodes can be protected by locks. Given two nodes n i and n j The main purpose of lock set analysis is to infer n i and n j Are they protected by the same lock? Given a node n i , CONCODEQL first builds a lock set for each of its thread-aware contexts Define the lock set as express It consists only of lock acquisition nodes whose corresponding locks in the current context have not been released; CONCODEQL then determines n by checking whether the lock sets overlap each other. i and n j Whether it is protected by the same lock; use the following formula to determine n i and n j PSL relationship: Then perform on-demand pointer analysis for concurrency enhancement: (1) Global variables: By analyzing CCPG and value stream graph, we designed an accurate analysis of global variables. First, we identified all global variable declarations by traversing CCPG to obtain a set of global variables. Then, we reconstructed the connection between global variables and local variables in VFG, and determined the global variable aliases through flow-sensitive pointer analysis. (2) Structure: For the access node of structure s, the specific attributes of the node access are simply obtained through CPG using regular expression judgment. CONCODEQL analyzes CCPG and VFG at the same time, and adjusts the structure representation to specific attributes in pointer analysis; Thread-aware flow-sensitive analysis: First, we need to traverse the initial CCPG and build a thread-aware context for each node; CONCODEQL first obtains all main entry nodes from CCPG and initializes their contexts to empty; In the main loop, if the current node with the current context is visited, CONCODEQL will terminate the loop directly; otherwise, CONCODEQL will traverse CCPG along the thread lifecycle edges and control flow edges. If the current node n is a FORK node that creates a new thread, the context of the entry node n' of the new thread will be initialized to each context previously added to node n, and a new thread t will be created. new ; If the current node n is not a FORK node, it simply traverses along the control flow edge and propagates the context of the current node to the subsequent nodes; the context constructed for each node is then used for the subsequent happens-before relationship and lock set analysis; Then, based on the context of each node, CONCODEQL traverses any pair of threads and checks whether their memory accesses to the nodes can occur in parallel; specifically, if two nodes n i and n j If both of them meet the following conditions: 1) access the same memory location; 2) may occur in parallel; and 3) are not protected by the same lock, CONCODEQL will i , n j ); finally, the algorithm generates an updated graph CCPG.

4. According to claim 1, a concurrency vulnerability detection method based on code concurrency attribute graph is characterized in that: The specific method of S3 is: A domain specific language is defined as a grammar L = {V T , V N , P, S}, where V T is a set of terminal symbols, V N It is a set of non-terminal symbols. The set of production rules P constitutes the main structural unit of the grammar. Each production rule p i It is expressed as α::=β, which describes the method of combining elements in the terminal symbol set and the non-terminal symbol set into a string, where S is the start symbol; The DSL is designed by using and extending the query statements used in the CodeQL DSL; in this structure, <query>It represents the starting symbol S in the definition and serves as the entry point for the domain-specific language;<var_delcs> Indicates variable declaration, including basic variable types and built-in variable types <built-intype> ； <condition>Define constraints in queries; <returns> Specify the value returned by the query;< / returns> < / condition> < / built-intype> < / query> The language's specificity to the concurrency domain is reflected in the structure <built-intype> and<concurrent_relation_condition> middle;<concurrent_relation_condition> Include<access_condition> ,<hb_relationship> and<lock_condition> , respectively handle thread-aware pointer analysis, happens-before relationships, and lock set analysis;< / built-intype> The lock analysis includes the IS_PROTECTED_BY and IS_AUTOMATICALLY_PROTECTED_BY methods, the former determines whether two variables are protected by the same lock, and the latter checks whether the operations are within the same critical section to ensure atomicity.

Images