Kernel data race detection method based on static program analysis and fuzz testing

Abstract

The present invention discloses a kernel data competition detection method based on static program analysis and fuzzy testing. The method identifies shared resources in the code through static program analysis, obtains access operations for shared resources, records the read and write properties of the access operations, and determines access pairs of potential data competition. By analyzing the semantics of kernel synchronization primitives, shared resource access pairs that are unlikely to generate thread interleaving are filtered to generate a more accurate data competition pair set. Kernel resources and system calls are identified through static analysis, and a system call dependency graph is constructed. The data competition pair set and the system call dependency graph are used to guide the generation and mutation of kernel fuzzy test cases. A thread-aware fuzzy test generator is used to randomize the priority of threads to explore thread interleaving, and runtime feedback information is used to update the edge weights of the dependency graph, improve the system call dependency graph, and guide the mutation of subsequent fuzzy test inputs.

Description

Technical Field

[0001] The invention relates to static program analysis technology and kernel fuzzy testing technology, which utilizes the kernel synchronization primitive features of an operating system to provide more effective information to guide the generation and mutation operation of kernel fuzzy testing, and belongs to the field of software engineering. Background Art

[0002] The operating system is system software that manages computer hardware and software resources, and the kernel is the core of the operating system. It abstracts and encapsulates various underlying hardware and exposes interfaces for user programs to use. Unlike user-mode programs, the kernel runs in the kernel mode with the highest permissions. Once a security vulnerability occurs, it directly affects the entire operating system and user programs. Fuzz testing is an automated software testing technology. Its core idea is to automatically or semi-automatically generate random data input into the target program and monitor program exceptions to discover possible program errors. It is one of the common vulnerability mining technologies.

[0003] Concurrency defects refer to two or more threads accessing shared resources in an unexpected order, resulting in uncertain results. Concurrency defects can be divided into deadlock defects and non-deadlock concurrency defects. The commonly detected object is the race condition in non-deadlock concurrency defects, and the race conditions are often summarized into three types of defects: atomicity violation, order violation, and data race. Among them, atomicity violation refers to the destruction of atomicity of the shared memory area that should be atomic due to interleaved execution, resulting in uncertain results; order violation refers to the failure of two memory accesses to be executed in the expected order, resulting in uncertain results; data race refers to multiple threads accessing shared memory at the same time without order requirements and at least one is a write operation, resulting in uncertain results.

[0004] The present invention uses static analysis technology to analyze the potential data contention pairs and system call dependency graph of the operating system, and then uses kernel synchronization primitives to analyze and filter data contention pairs that are unlikely to have thread interleaving, and guides kernel fuzzy testing to generate and mutate system call sequence operations, and detects operating system kernel data contention through virtualizer-based kernel fuzzy testing. Summary of the invention

[0005] The current operating system kernel fuzz testing does not consider kernel synchronization primitives. In order to solve the above technical problems, the present invention adopts the following technical solutions:

[0006] The present invention proposes a kernel data competition detection method based on static program analysis and fuzzy testing, comprising the following steps:

[0007] Step 1: Identify shared resources in the code through static program analysis, obtain access operations for shared resources, record the read and write attributes of the access operations, determine the access pairs of potential data contention, and then filter the shared resource access pairs that are unlikely to cause thread interleaving by analyzing the semantics of kernel synchronization primitives to generate a more accurate set of data contention pairs. The specific steps are as follows;

[0008] Step 1.1: Partition the operating system kernel module;

[0009] Step 1.2: Perform inter-procedural and context-sensitive static program analysis on the operating system kernel code of each partition to obtain access operations and read and write properties for shared resources;

[0010] Step 1.3: Detect potential data race pairs of the operating system through point pair analysis and generate a set of potential data race pairs;

[0011] Step 1.4: Classify and summarize the corresponding patterns of the characteristics of the operating system kernel synchronization primitives;

[0012] Step 1.5: By analyzing the kernel synchronization primitives, find out the multi-threaded statements that are restricted by the synchronization mechanism during actual runtime, filter out the data contention pairs that will not cause thread interleaving in the set of potential data contention pairs, and generate a more accurate set of data contention pairs.

[0013] Step 2: Identify kernel resources and system calls through static analysis and build a system call dependency graph. The specific steps are as follows:

[0014] Step 2.1: Define a directed weighted graph, where the nodes are system calls. Since the order of system call sequences is not fixed, any two system calls may appear in sequence, so an initial directed complete graph with edge weights of 0 is generated;

[0015] Step 2.2: Statically analyze the kernel source code and resources to obtain the kernel resource usage of each function;

[0016] Step 2.3: Analyze the dependencies between system calls, update the edge weights in the dependency graph, and improve the system call dependency graph.

[0017] Step 3: Use the data race pair set to guide the generation of kernel fuzz test cases and generate the initial fuzz test input through the shared resource access location of the data race pair. The specific steps are as follows:

[0018] Step 3.1: Traverse the data competition pair set and select the data competition pair currently ready to be used;

[0019] Step 3.2: Generate the initial input of the fuzz test, namely the system call sequence, where the system call sequence contains access to data competition pairs.

[0020] Step 4: Use the system call dependency graph to guide the mutation of kernel fuzz test cases. Use the edge weights of the system call dependency graph to add, delete, and replace system call statements according to probability to generate new fuzz test inputs. The specific steps are as follows:

[0021] Step 4.1: Based on the system call dependency graph mutation fuzz test initial input, when using the system call deletion strategy, select the system call with low continuous system call edge weight in the test case with a greater probability;

[0022] Step 4.2: When using the insertion system call strategy, the system call pointed to by the edge with a high weight starting from the predecessor node of the insertion point is selected with a higher probability;

[0023] Step 4.3: When using the replacement system call strategy, the system call pointed to by the edge with a high weight starting from the predecessor node of the replacement point is selected with a greater probability.

[0024] Step 5: Use a thread-aware fuzz generator to randomize thread priorities to explore thread interleaving and use runtime feedback information to update the edge weights of the dependency graph to improve the system call dependency graph and guide the mutation of subsequent fuzz test inputs. The specific steps are as follows:

[0025] Step 5.1: By running the target kernel in a customized virtualization environment;

[0026] Step 5.2: Set a breakpoint for each CPU core, with the breakpoint location on the data race statement;

[0027] Step 5.3: After the two kernel threads stop at their respective breakpoint addresses, that is, after accessing the data race pair in the set, resume the execution of the virtual CPU;

[0028] Step 5.4: Check whether there is actual data competition in the virtual core, and make a judgment by accessing the same address through CPU instructions;

[0029] Step 5.5: Collect runtime information. When the system runs successfully or detects data competition, increase the edge weights between system call sequences, update the system call dependency graph, and guide the mutation of subsequent fuzz testing inputs.

[0030] Beneficial effects: Compared with the prior art, the present invention adopts the above technical solution and has the following beneficial effects:

[0031] 1. This method considers the operating system kernel primitives, filters out potential data race pairs that are unlikely to occur, and reduces invalid inputs for fuzz testing.

[0032] 2. This method uses a virtual machine scheduler to schedule threads, allowing threads to trigger potential data contention pairs as much as possible to improve the efficiency of fuzz testing.

[0033] 3. This method improves the effectiveness of fuzz test input by using the system call dependency graph to guide the mutation of fuzz test input. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] Figure 1 It is a system framework for kernel data competition detection methods based on static program analysis and fuzz testing. DETAILED DESCRIPTION

[0035] The following is a more detailed description of a specific embodiment of the kernel fuzzy test case generation method based on the system call dependency graph used in the present invention in conjunction with the accompanying drawings.

[0036] The kernel data competition detection method based on static program analysis and fuzz testing of this embodiment includes the following steps:

[0037] Step 1: Identify shared resources in the code through static program analysis, obtain access operations for shared resources, record the read and write attributes of the access operations, determine the access pairs of potential data contention, and then filter the shared resource access pairs that are unlikely to cause thread interleaving by analyzing the semantics of kernel synchronization primitives to generate a more accurate set of data contention pairs. The specific steps are as follows;

[0038] Step 1.1: Partition the operating system kernel module;

[0039] Step 1.2: Perform inter-procedural and context-sensitive static program analysis on the operating system kernel code of each partition to obtain access operations and read and write properties for shared resources;

[0040] Step 1.3: Detect potential data race pairs of the operating system through point pair analysis and generate a set of potential data race pairs;

[0041] Step 1.4: Classify and summarize the corresponding patterns of the characteristics of the operating system kernel synchronization primitives;

[0042] Step 1.5: By analyzing the kernel synchronization primitives, find out the multi-threaded statements that are restricted by the synchronization mechanism during actual runtime, filter out the data contention pairs that will not cause thread interleaving in the set of potential data contention pairs, and generate a more accurate set of data contention pairs.

[0043] Step 2: Identify kernel resources and system calls through static analysis and build a system call dependency graph. The specific steps are as follows:

[0044] Step 2.1: Define a directed weighted graph, where the nodes are system calls. Since the order of system call sequences is not fixed, any two system calls may appear in sequence, so an initial directed complete graph with edge weights of 0 is generated;

[0045] Step 2.2: Statically analyze the kernel source code and resources to obtain the kernel resource usage of each function;

[0046] Step 2.3: Analyze the dependencies between system calls, update the edge weights in the dependency graph, and improve the system call dependency graph.

[0047] Step 3: Use the data race pair set to guide the generation of kernel fuzz test cases and generate the initial fuzz test input through the shared resource access location of the data race pair. The specific steps are as follows:

[0048] Step 3.1: Traverse the data competition pair set and select the data competition pair currently ready to be used;

[0049] Step 3.2: Generate the initial input of the fuzz test, namely the system call sequence, where the system call sequence contains access to data competition pairs.

[0050] Step 4: Use the system call dependency graph to guide the mutation of kernel fuzz test cases. Generate the initial fuzz test input through the shared resource access location of the data competition pair. Add, delete and replace system call statements according to the probability through the edge weights of the system call dependency graph to generate new fuzz test input. The specific steps are as follows:

[0051] Step 4.1: Based on the system call dependency graph mutation fuzz test initial input, when using the system call deletion strategy, select the system call with low continuous system call edge weight in the test case with a greater probability;

[0052] Step 4.2: When using the insertion system call strategy, the system call pointed to by the edge with a high weight starting from the predecessor node of the insertion point is selected with a higher probability;

[0053] Step 4.3: When using the replacement system call strategy, the system call pointed to by the edge with a high weight starting from the predecessor node of the replacement point is selected with a greater probability.

[0054] Step 5: Use a thread-aware fuzz generator to randomize thread priorities to explore thread interleaving and use runtime feedback information to update the edge weights of the dependency graph to improve the system call dependency graph and guide the mutation of subsequent fuzz test inputs. The specific steps are as follows:

[0055] Step 5.1: By running the target kernel in a customized virtualization environment;

[0056] Step 5.2: Set a breakpoint for each CPU core, with the breakpoint location on the data race statement;

[0057] Step 5.3: After the two kernel threads stop at their respective breakpoint addresses, that is, after accessing the data race pair in the set, resume the execution of the virtual CPU;

[0058] Step 5.4: Check whether there is actual data competition in the virtual core, and make a judgment by accessing the same address through CPU instructions;

[0059] Step 5.5: Collect runtime information. When the system runs successfully or detects data competition, increase the edge weights between system call sequences, update the system call dependency graph, and guide the mutation of subsequent fuzz testing inputs.

[0060] This method generates valid test cases, i.e., system call sequences, as much as possible while considering the kernel synchronization mechanism. This method obtains a set of data race pairs and a system call dependency graph by statically analyzing the kernel source code. The data race pairs and dependency graph are used to guide the generation and mutation operations in fuzz testing, thereby improving the validity of fuzz test inputs as much as possible and increasing the possibility of triggering data race vulnerabilities.

[0061] The above is only to illustrate the technical idea of ​​the present invention, and cannot be used to limit the protection scope of the present invention. Any changes made on the basis of the technical solution according to the technical idea proposed by the present invention shall fall within the protection scope of the present invention. The technologies not involved in the present invention can be realized by existing technologies.

Claims

1. A kernel data competition detection method based on static program analysis and fuzz testing, the method comprising the following steps: Step 1: Identify shared resources in the code through static program analysis, obtain access operations to shared resources, record the read and write properties of the access operations, determine access pairs with potential data contention, and then filter shared resource access pairs that are unlikely to cause thread interleaving by analyzing the semantics of kernel synchronization primitives to generate a more accurate set of data contention pairs; The step 1 is specifically as follows: Step 1.1: Partition the operating system kernel module; Step 1.2: Perform inter-procedural and context-sensitive static program analysis on the operating system kernel code of each partition to obtain access operations and read and write properties for shared resources; Step 1.3: Detect potential data race pairs of the operating system through point pair analysis and generate a set of potential data race pairs; Step 1.4: Classify and summarize the corresponding patterns of the characteristics of the operating system kernel synchronization primitives; Step 1.5: Analyze kernel synchronization primitives to find multi-threaded statements that are restricted by the synchronization mechanism during actual runtime, filter out data race pairs that will not cause thread interleaving in the potential data race pair set, and generate a more accurate data race pair set; Step 2: Identify kernel resources and system calls through static analysis and build a system call dependency graph; Step 3: Use the data race pair set and the guide kernel fuzz test case generation to generate the initial fuzz test input through the shared resource access location of the data race pair; The step 3 is as follows: Step 3.1: Traverse the data competition pair set and select the data competition pair currently ready to be used; Step 3.2: Generate the initial input of the fuzz test, i.e., the system call sequence, wherein the system call sequence contains access to the data competition pair; Step 4: Use the system call dependency graph to guide the mutation of kernel fuzz test cases. Use the edge weights of the system call dependency graph to add, delete, or replace system call statements according to probability to generate new fuzz test inputs. The step 4 is specifically as follows: Step 4.1: Based on the system call dependency graph mutation fuzz test initial input, when using the system call deletion strategy, select the system call with low continuous system call edge weight in the test case with a greater probability; Step 4.2: When using the insertion system call strategy, the system call pointed to by the edge with a high weight starting from the predecessor node of the insertion point is selected with a higher probability; Step 4.3: When using the replacement system call strategy, the system call pointed to by the edge with a high weight starting from the predecessor node of the replacement point is selected with a higher probability; Step 5: Use a thread-aware fuzz generator to randomize thread priorities to explore thread interleaving, and use runtime feedback information to update the edge weights of the dependency graph to improve the system call dependency graph and guide the mutation of subsequent fuzz test inputs.

2. The kernel data competition detection method based on static program analysis and fuzz testing according to claim 1 is characterized in that: The specific steps of step 2 are as follows: Step 2.1: Define a directed weighted graph, where the nodes are system calls. Since the order of system call sequences is not fixed, any two system calls may appear in sequence, so an initial directed complete graph with edge weights of 0 is generated; Step 2.2: Statically analyze the kernel source code and resources to obtain the kernel resource usage of each function; Step 2.3: Analyze the dependencies between system calls, update the edge weights in the dependency graph, and improve the system call dependency graph.

3. The kernel data competition detection method based on static program analysis and fuzz testing according to claim 1 is characterized in that: The step 5 is specifically as follows: Step 5.1: By running the target kernel in a customized virtualization environment; Step 5.2: Set a breakpoint for each CPU core, with the breakpoint location on the data race statement; Step 5.3: After the two kernel threads stop at their respective breakpoint addresses, that is, after accessing the data race pair in the set, resume the execution of the virtual CPU; Step 5.4: Check whether there is actual data competition in the virtual core, and make a judgment by accessing the same address through CPU instructions; Step 5.5: Collect runtime information. When the system runs successfully or detects data competition, increase the edge weights between system call sequences, update the system call dependency graph, and guide the mutation of subsequent fuzz testing inputs.

4. The kernel data competition detection method based on static program analysis and fuzz testing according to any one of claims 1 to 3, characterized in that: The kernel synchronization primitives in step 1 include a series of primitives with different semantics, such as mutex locks, semaphores, spin locks, and sequential locks.

5. The kernel data competition detection method based on static program analysis and fuzz testing according to claim 4 is characterized in that: Static program analysis of different kernel synchronization primitives to identify potential data race pairs that do not interleave with threads.

Images