A method for predicting upper bound of program resource consumption based on resource usage-aware fuzz testing
Through the method based on resource usage perception fuzz testing, combined with static analysis and dynamic fuzz testing, identify resource operation API and control flow branches, and use modeling functions of instrumented resource resources, the upper bound prediction accuracy of resource consumption in the existing technology is solved. The problem is to achieve accurate resource consumption prediction for large-scale complex programs.
Patent Information
- Application Number
- CN202210314578.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-03-28
- Publication Date
- 2024-12-20
- Estimated Expiration
- 2042-03-28
AI Technical Summary
When predicting program resource consumption upper bound, the prior art is not very accurate and difficult to apply to large-scale complex programs. Traditional static analysis methods cannot accurately predict the consumption of multiple resource types in the worst-case scenario.
Using a method based on resource usage-aware fuzz testing, identify resource operation APIs and control flow branches through static analysis, instrument resource use modeling functions and coverage label functions, and combine dynamic fuzz testing to obtain the worst-case resources of the target program. consumption.
It improves the accuracy and applicability of upper bound prediction of resource consumption, can accurately predict the worst-case consumption of multiple resource types in large-scale complex programs, and reduces the limitation on program complexity.
Smart Images

Figure CN114741282B_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of software testing, and in particular to a method for predicting an upper bound of program resource consumption based on resource usage-aware fuzzy testing. Background Art
[0002] The use and management of resources in computer systems has always been one of the important concerns of software development. When running, software inevitably needs to operate and manage various resources, such as stack memory, threads, file handles, database connections, network sockets, etc. As the program runs (such as opening or closing files), the usage of each resource (such as the number of currently open file handles) will change dynamically with the program running, and different programs consume different types of resources. If the program is configured with fewer system resources or the program itself has uncontrolled resource consumption defects, it may cause the entire system to have a reduced operating efficiency or operation obstruction, or even crash. Therefore, predicting and analyzing the upper limit of program resource consumption in advance is of great significance for detecting program resource consumption defects, optimizing resource allocation, and ensuring the correct operation of the program.
[0003] The purpose of predicting the upper bound of program resource consumption is to predict the upper bound of the amount of resources consumed during program operation under the worst-case scenario. For the prediction of the upper bound of resource consumption, static analysis methods are currently usually used. The complex grammatical structure in the source program is abstracted to obtain a pure numerical program and then the analysis is carried out. The number of iterations of the loop (or recursion) is derived in a conservative way. The analysis result is generally a linear expression about the input. The heap memory consumption is mainly considered during the analysis process. The above-mentioned traditional static analysis method is used to predict the upper bound of program resource consumption. It usually includes the following steps: introducing integer variables to model resource usage in the program, adding resource usage modeling statements, and modeling the changes in resource usage in program statements; based on the program source code after adding modeling statements, static analysis (such as symbolic execution, abstract interpretation, etc.) is carried out to analyze and obtain the upper bound of the value range of the resource usage modeling variable.
[0004] However, the above traditional method of using static analysis methods to predict the upper bound of program resource consumption has the following problems:
[0005] 1. Although traditional static analysis methods can provide an upper limit for resource consumption in the worst case, they can only provide overly conservative or even unlimited results. The predicted upper limit of resource consumption in the worst case obtained by analysis is significantly different from the actual resource consumption in the worst case of the program, that is, the prediction accuracy is not high.
[0006] 2. It is only applicable to predictions of small-scale programs. Complex grammatical structures need to be abstracted. In real-world programs, resources are usually operated through specific APIs (Application Programming Interfaces), which may involve complex structures. Therefore, traditional static analysis methods are not applicable to large-scale complex programs. Summary of the invention
[0007] The technical problem to be solved by the present invention is: in response to the technical problems existing in the prior art, the present invention provides a method for predicting the upper bound of program resource consumption based on resource usage-aware fuzzy testing, which has a simple implementation method, a high degree of automation, and high prediction efficiency and accuracy. It can achieve accurate prediction of resource consumption of multiple resource types in large-scale programs under the worst case scenario.
[0008] In order to solve the above technical problems, the technical solution proposed by the present invention is:
[0009] A method for predicting the upper bound of program resource consumption based on resource usage-aware fuzz testing, comprising the following steps:
[0010] Step S1. Using a static analysis method, identify the resource operation API of the specified resource type in the target program, identify the functions involved in resource usage, and identify the control flow branch where the resource usage is located, and insert the call statements of the pre-defined resource usage modeling function and the coverage label function for code coverage marking into the target program to obtain the inserted program;
[0011] Step S2: Using resource consumption and resource usage operation coverage as a guide, fuzz testing is performed on the instrumented program to obtain the resource consumption of the target program in the worst case, which is the predicted upper bound of program resource consumption.
[0012] Furthermore, the step S1 includes:
[0013] Step S101. Identify resource operation API: The resource usage operation API includes an application programming interface provided by a system or library, and an application programming interface defined in an application. For the resource usage operation, a corresponding resource usage modeling function is defined, and the resource modeling function is inserted into a specified position in a target program. The resource usage is modeled by explicitly calling the resource usage modeling function in the target program.
[0014] Step S102. Identify functions involved in resource usage: According to the resource operation API obtained in step S101 and the function call graph of the target program, identify a list of all functions that directly or indirectly call resource usage operations, and insert a preset coverage label function before calling the location of each identified function to identify basic blocks involved in resource usage in the program;
[0015] Step S103. Identify the control flow branch where the resource is used: obtain all target program blocks that contain the resource usage modeling function or the coverage label function, identify the control flow branch where the target program block is located, and insert a preset coverage label function before the control flow branch where the target program block is located and at the beginning of the program block of another branch.
[0016] Furthermore, the resource usage modeling function includes a first modeling function _RAlloc(intn) and a second modeling function _RDealloc(intn), wherein the first modeling function _RAlloc(intn) is used to model the allocation of resource quantity n, that is, adding n to the current resource usage res_now, wherein if the current resource usage res_now is more than the current resource usage peak res_peak, the value of the resource usage res_now is assigned to the current resource usage peak res_peak; the second modeling function _RDealloc(intn) is used to model the release of resource quantity n, that is, subtracting n from the current resource usage (res_now).
[0017] Furthermore, the preset coverage label function is a _covl() function, that is, in the step S102, the function _covl() is inserted to identify the basic blocks involving resource usage in the program by the function _covl(), and the function _covl() is an empty function; in the step S103, the function _covl() is inserted before the control flow branch where the target program block is located and at the beginning of the program block of another branch.
[0018] Furthermore, in the step S103, the preset coverage label function is instrumented by adopting a bottom-up instrumentation method, that is, instrumentation starts from the innermost branch that meets the matching conditions and continues to the outermost branch, and the innermost branch that meets the matching conditions is a branch that contains a resource usage operation API.
[0019] Furthermore, in the step S1, a program instrumentation tool based on semantic patches is used to automatically instrument the calling statements of the resource usage modeling function and the coverage labeling function into the target program.
[0020] Furthermore, the steps of step S2 include:
[0021] Step S201. Input the instrumented program and the initial input case, initialize the currently found maximum resource consumption max_res to 0, and initialize the fuzzy test seed sequence to a queue composed of the initial input case;
[0022] Step S202. Execute fuzz testing, select an input from the fuzz test seed sequence and mutate it each time, generate a mutated input, run the mutated input and monitor the execution status, collect resource usage information and resource usage perception coverage information, and obtain the maximum resource consumption of the current execution after the execution ends;
[0023] Step S203. Determine the maximum value of the resource consumption of the current execution. If it is greater than the currently found maximum resource consumption max_res, assign the maximum value of the resource consumption of the current execution to the currently found maximum resource consumption max_res, and add it to the fuzz test seed sequence to continue to apply mutation to generate test cases; or if the resource usage position that was not covered before is covered during the execution of the current mutated input, add the current mutated input to the seed sequence;
[0024] Step S204. Determine whether the execution of the current input will cause the program to crash. If so, add the current input to the test case set BuggyS that collects and triggers resource usage errors. After completing the fuzz test of the current input, obtain the maximum value of resource consumption within a given time and the test case set BuggyS that triggers resource usage errors and output them.
[0025] Furthermore, in the step S202, during the execution of the fuzzy test, the fuzzy test engine tracks the current resource usage of the current execution and the maximum resource consumption max_res currently found, updates the resource usage by capturing the parameters of the resource usage modeling function, and updates the current amount and historical peak amount of resource usage.
[0026] Furthermore, during the fuzz testing process, the jumps between basic blocks including resource usage modeling functions and coverage labeling functions are recorded to guide the fuzz testing.
[0027] Furthermore, during the fuzz testing process, the resource usage-aware fuzzer uses different branch coverage definitions, takes resource usage operations as coverage targets, and adds resource consumption as a guide. If the current input has new resource usage-aware coverage, the current input is added to the fuzz testing seed sequence for further mutation.
[0028] Compared with the prior art, the advantages of the present invention are:
[0029] 1. The present invention uses a combination of dynamic and static methods to first perform static analysis and code insertion on the program. Since the inserted code can ensure that the functions of the program remain completely unchanged and will not affect the operating efficiency of the program, the program after the insertion is then fuzzy tested. The entire prediction process is independent of the complexity of the analyzed program and can be applied to large-scale complex programs. Compared with the traditional static analysis method, which requires abstracting the complex grammatical structure in the source program before analysis, it can greatly reduce the limitation of the upper bound prediction of program resource consumption on program complexity.
[0030] 2. The present invention realizes the prediction of the upper limit of program resource consumption by adopting a dynamic analysis method based on resource usage-aware fuzzy testing, which can maximize the consumption of triggered resources, and the resource consumption triggered by each operation is the real consumption of the program. Therefore, the prediction result of the upper limit of program resource consumption can be close to the upper limit of resource consumption in the actual worst case of the program, which greatly improves the prediction accuracy of the upper limit of program resource consumption. BRIEF DESCRIPTION OF THE DRAWINGS
[0031] Figure 1 It is a schematic diagram of the implementation flow of the method for predicting the upper bound of program resource consumption based on resource usage-aware fuzzy testing in this embodiment.
[0032] Figure 2 A flowchart of implementing automatic code instrumentation according to step S1 in a specific application embodiment. DETAILED DESCRIPTION
[0033] The present invention is further described below in conjunction with the accompanying drawings and specific preferred embodiments, but the protection scope of the present invention is not limited thereby.
[0034] like Figure 1 As shown, the steps of the method for predicting the upper bound of program resource consumption based on resource usage-aware fuzzy testing in this embodiment include:
[0035] Step S1. Using a static analysis method, identify the resource operation API of the specified resource type in the target program, identify the functions involved in resource usage, and identify the control flow branch where the resource usage is located, and insert the call statements of the pre-defined resource usage modeling function and the coverage label function for code coverage marking into the target program to obtain the inserted program;
[0036] Step S2: Using resource consumption and resource usage operation coverage as a guide, perform fuzz testing on the instrumented program to obtain the resource consumption of the target program in the worst case, which is the predicted upper bound of program resource consumption.
[0037] This embodiment uses a combination of dynamic and static methods. First, the program is statically analyzed and the code is plugged in. The plugged code can ensure that the program's functions remain completely unchanged and will not affect the program's operating efficiency. Then, the plugged program is fuzz tested. Based on the dynamic analysis of resource-usage-aware fuzz testing, the upper limit of program resource consumption is predicted by combining fuzz testing guided by resource consumption maximization and resource usage operation coverage. On the one hand, since the entire prediction process is independent of the complexity of the analyzed program, it can be applied to large-scale complex programs in the real world; on the other hand, the fuzz testing method based on resource-usage awareness can maximize the consumption of triggered resources, and the resource consumption triggered by each run is the real consumption of the program, so that the prediction result of the upper limit of program resource consumption is close to the upper limit of resource consumption in the actual worst case of the program, ensuring the final prediction accuracy.
[0038] like Figure 1 As shown, step S1 corresponds to executing automated program conversion, using static analysis methods to respectively identify resource-related operations, functions involving resource usage, and control flow branches where resource usage is located in the target program, and then automatically inserting the code to insert the calling statements of the resource usage modeling function and the coverage label function into the target program to obtain the inserted program; step S2 performs a fuzzy test cycle on the inserted program obtained in step S1, and uses resource usage operation coverage and resource consumption as guidance during the test, and finally obtains the resource consumption peak of the target program in the worst case, that is, obtains the upper bound of the program resource consumption required to be predicted.
[0039] The steps of step S1 in this embodiment include:
[0040] Step S101. Identify resource operation APIs: resource usage operation APIs include application programming interfaces provided by the system or library, and application programming interfaces defined in applications (such as programmer-defined ones). For the above resource usage operations, define corresponding resource usage modeling functions, and insert the resource modeling functions into a specified position in the target program. By explicitly calling the resource usage modeling functions in the target program, model resource usage.
[0041] Step S102. Identify functions involved in resource usage: According to the resource operation API obtained in step S101 and the function call graph of the target program, identify a list of all functions that directly or indirectly call resource usage operations, and insert a preset coverage label function before calling the location of each identified function to identify basic blocks involved in resource usage in the program;
[0042] Step S103. Identify the control flow branch where resources are used: obtain all target program blocks that contain resource usage modeling functions or the coverage label function, identify the control flow branch where the target program block is located, and insert a preset coverage label function before the control flow branch where the target program block is located and at the beginning of the program block of another branch.
[0043] The resource usage operation API can be an application programming interface provided by the system or library, or it can be an application programming interface customized by the programmer in the application, such as the heap memory application function malloc. From the perspective of the increase or decrease of resource usage, all resource usage operations can essentially be simply classified into allocation (i.e., increase) and release (i.e., decrease) operations. In this embodiment, for each resource operation API corresponding to the resource type, two basic resource usage modeling functions are defined to simulate the change of resource usage, as shown in Table 1, including a first modeling function _RAlloc (intn) and a second modeling function _RDealloc (intn), the first modeling function _RAlloc (intn) is used to model the allocation of the number of resources n, that is, the current resource usage res_now plus n, wherein if the current resource usage res_now is more than the current resource usage peak res_peak, the value of the current resource usage res_now is assigned to the current resource usage peak res_peak, that is, the current resource usage peak res_peak is the current resource usage res_now; the second modeling function _RDealloc (intn) is used to model the release of the number of resources n, that is, the current resource usage (res_now) is subtracted from n.
[0044] Table 1 Resource operation modeling functions
[0045]
[0046] After defining the above two basic modeling functions, the calls of the above two basic modeling functions will be inserted, and the two basic modeling functions will be explicitly called for each resource usage operation in the original program to model resource usage. For example, in order to model pFile = fopen (...), you can insert _RAlloc (pFile! = NULL? 1: 0) after this statement; in order to model free (p) in a C program, you can insert _RDealloc (malloc_usable_size (p)) before this statement, where the malloc_usable_size (p) function (C language library function) returns the number of bytes occupied by the dynamic storage block pointed to by p; in order to simulate the change of stack depth, you can insert _RAlloc (1) and _RDealloc (1) at the entry and end of each function (before the return statement).
[0047] This embodiment only considers one type of resource in each prediction analysis, and different resources are implemented by using multiple prediction analyses to avoid mutual influence between multiple types of resources.
[0048] In a specific application embodiment, in step S102, a list of all functions that directly or indirectly call resource usage operations is identified based on the resource operation API obtained in step S101 and the function call graph of the target program, and then a coverage label function _covl() is inserted before the locations of these target functions are called, so that the basic blocks involved in resource usage in the program are identified by function _covl(), and the basic blocks will be further used to define the resource usage-aware coverage in step S2, and function _covl() is an empty function.
[0049] In a specific application embodiment, in step S103, for each program block containing a resource usage modeling function (_RAlloc, _RDealloc) or a coverage label function (i.e., _covl), the control flow branch where the program block is located is identified, and the coverage label function _covl() is inserted before the control flow branch where the program block is located and at the beginning of the program block of another branch (such as the else branch). Specifically, a bottom-up insertion method can be adopted, that is, inserting from the innermost branch that meets the matching conditions to the outermost branch, and the innermost branch that meets the matching conditions is the branch containing the resource usage operation API.
[0050] It is understandable that the above-mentioned identification of resource operation APIs, functions related to resource usage, and identification of control flow branches where resources are located can of course also be implemented by other methods according to actual needs to obtain program resource usage.
[0051] In step S1 of this embodiment, a program instrumentation tool based on semantic patches is specifically used to automatically instrument the call statements of resource usage modeling functions and coverage label functions into the target program to achieve automatic code instrumentation. The program instrumentation tool based on semantic patches allows the writing of semantic patches to specify the required code matching and program conversion methods. For example, the conversion engine of the program instrumentation tool Coccinelle based on semantic patches is defined based on control flow, so it is very suitable for inserting coverage label functions at the control flow branch where resource usage is located.
[0052] Take for example code extracted from an old version of libtirpc that contains a known CVE vulnerability (e.g. Figure 2 The CVE phenomenon occurs because the return value of makefd_xprt() is not checked in all instances, which may lead to a crash when the server runs out of the maximum number of available file descriptors. Figure 2(a) shows a slice extracted from the original code of libtirpc. Figure 2 (b) shows part of the semantic patch applied to the tool. The program after instrumentation is as follows Figure 2 The program uses a socket connection, for example by calling Figure 2 The accept() function shown in line 13 of (a) above. Figure 2 The semantic patch shown in (b) inserts the resource usage modeling function _RAlloc(1) and the coverage labeling function _covl() at the program location when the connection is successfully established. The inserted code is as follows Figure 2 As highlighted in (c).
[0053] It is understandable that the above automatic code instrumentation can also be implemented by other instrumentation methods. The key is that the inserted auxiliary variable statement can accurately characterize the resource usage of the program and the changes in the upper limit of the usage.
[0054] For the target program and the resource type to be estimated, this embodiment first uses a static analysis method to identify the resource operation API of the specified resource type to be analyzed and a list of all functions that directly or indirectly call resource usage operations, as well as all program locations (i.e., program points) where all functions in the above resource operation API and function list are called, and for each resource operation API corresponding to the resource type, a corresponding resource usage modeling function is defined to simulate the change in resource usage; on this basis, for the source code of the target program to be analyzed, the control flow branch where the resource usage is located is identified, and then a program instrumentation tool based on semantic patches is used to automatically insert the resource usage modeling function and the calling statements of the label function used for code coverage marking into the original program, and the instrumented code ensures that the functionality of the program remains completely unchanged and will not affect the running efficiency of the program.
[0055] In this embodiment, step S2 includes:
[0056] Step S201. Input the instrumented program and the initial input case, initialize the currently found maximum resource consumption max_res to 0, and initialize the fuzzy test seed sequence to a queue consisting of the initial input case;
[0057] Step S202. Execute the fuzz test, select an input from the fuzz test seed sequence and mutate it each time, generate the mutated input, run the mutated input and monitor the execution, collect resource usage information and resource usage perception coverage information, and obtain the maximum resource consumption of the current execution after the execution ends;
[0058] Step S203. Determine the maximum value of the resource consumption of the current execution. If it is greater than the currently found maximum resource consumption max_res, assign the maximum value of the resource consumption of the current execution to the currently found maximum resource consumption max_res, and add it to the fuzz test seed sequence to continue to apply mutation to generate test cases; or if the execution process of the current mutated input covers the resource usage position that was not covered before, add the current mutated input to the seed sequence;
[0059] Step S204. Determine whether the execution of the current input will cause the program to crash. If so, add the current input to the test case set BuggyS that collects and triggers resource usage errors. After completing the fuzz test of the current input, obtain the maximum value of resource consumption within a given time and the output of the test case set BuggyS that triggers resource usage errors.
[0060] This embodiment adopts a resource-usage-aware fuzz testing method, combined with fuzz testing guided by resource consumption maximization and resource usage operation coverage to obtain the resource consumption of the program in the worst case. It can maximize the consumption of triggered resources, so that the prediction result of the upper limit of the final program resource consumption can be close to the actual resource consumption of the program in the worst case.
[0061] like Figure 1 As shown, during the execution of the fuzz testing cycle, first an input is selected from the seed sequence and mutated to generate the mutated input, the mutated input is executed and the execution is monitored, resource usage information and resource usage awareness coverage information are collected, the collected information is fed back, and the resource consumption and resource usage operation coverage are combined as fuzz testing guidance to update the seed sequence until the final prediction result of the program resource consumption peak (upper bound) is obtained.
[0062] This embodiment configures an algorithm for implementing fuzz testing, the algorithm inputs the program after the plugging in step S1 and the initial input case, and the output after the test is completed is (max_res, BuggyS), where max_res is the maximum resource consumption currently found, and BuggyS is the test case set that triggers the resource consumption vulnerability. When executing the test, in step S201, max_res is first initialized to 0, BuggyS is an empty set, and the fuzzy test seed sequence is initialized to a queue composed of the initial input case.
[0063] In step S202 of this embodiment, during the execution of the fuzzy test, the fuzzy test engine tracks the current resource usage of the current execution and the maximum resource consumption max_res currently found, updates the resource usage by capturing the parameters of the resource usage modeling function, and updates the current amount and historical peak amount of resource usage.
[0064] In a specific application embodiment, step S202 specifically includes: during the fuzz test process, if the fuzz test running time does not exceed the preset threshold time limit, first select an input from the seed queue, mutate it and generate a mutated input, then run the mutated input and monitor its execution, collect information related to resource usage and resource usage perception coverage information, and during the execution process, the fuzz test engine maintains two variables (resc_cur and resc_peak) to track the current resource usage of the current execution and the maximum resource usage so far; the fuzz test engine then updates the resource usage by capturing the parameters of _RAlloc(n) and _RDealloc(n), as well as the current amount and historical peak amount of resource usage. After the current execution ends, the value of the maximum resource consumption resc_peak of the current execution can be obtained and assigned to the variable n_res.
[0065] In the fuzz testing process, this embodiment guides the fuzz testing by recording the jumps between basic blocks containing resource usage modeling functions and coverage label functions; many basic blocks in the program are useful for implementing the functions of the program, but have nothing to do with resource usage. Unlike traditional coverage-based gray box fuzz testing tools (e.g., AFL), this embodiment only focuses on resource usage in the program, that is, only records the jumps between basic blocks containing resource usage modeling functions (i.e., _RAlloc(), _RDealloc()), coverage label functions _covl(), and exit() functions to guide the fuzz testing. For example, consider the execution path only Contains the aforementioned resource-related functions, recording the execution path as arrive The conversion is executed and the hit count of this conversion is increased according to the specific execution situation.
[0066] In the fuzz testing process, in this embodiment, in terms of identifying different resource usages, the resource usage-aware fuzzer uses different branch coverage definitions, takes resource usage operations as coverage targets, and adds resource consumption as a guide to retain interesting inputs. If the current input has new resource usage-aware coverage, the current input is added to the fuzz test seed sequence for further mutation. Compared with the traditional edge coverage method, this embodiment can achieve more sophisticated and sensitive identification of different resource usages by using a resource usage-aware edge coverage method.
[0067] In a specific application embodiment, in step S203, if the maximum value of resource consumption n_res of the current execution is greater than the maximum resource consumption max_res currently found, indicating that the current mutated input consumes more resources, the value of n_res is assigned to max_res, that is, the maximum resource consumption max_res currently found is the maximum value of resource consumption n_res of the current execution, and the current mutated input is regarded as interesting, and is added to the seed sequence to continue to apply mutation to generate more test cases. If the resource usage position that was not covered before is covered during the execution of the current mutated input, the current mutated input is regarded as interesting and is added to the seed sequence.
[0068] In step S204 of this embodiment, when the running time allocated to the fuzz test is exhausted, the control ends the running process and outputs the result (max_res, BuggyS), that is, the maximum value max_res of resource consumption within a given time and the test case set BuggyS that triggers resource usage errors.
[0069] It is understandable that the above-mentioned fuzz testing based on resource usage awareness can also be implemented in other ways. The key is to perform fuzz testing guided by resource usage coverage and resource usage.
[0070] In summary, in real-world programs, resources are usually operated through specific APIs, which may involve complex structures, and the amount of resource usage often depends not only on specific parameters, but also on the operating system environment. For example, consider malloc(n) in a C program, the actual amount of heap memory allocated depends on the operating environment (depending on factors such as alignment, the first currently available free slot, etc.), and the above are all uncertain before execution, so the allocation may fail, or memory greater than n may be allocated (for example, due to alignment factors). The present invention adopts a combination of static and dynamic methods, and the resources concerned are the abstraction of resources provided to the application by the operating system system call API or library function, including heap memory, stack memory, file handles, etc., and divides program analysis into static analysis and dynamic analysis. A fuzzy testing method guided by resource usage perception that combines dynamic and static methods is adopted to achieve the prediction of the upper limit of program resource consumption, which can not only make it applicable to large-scale complex programs in the real world, but also greatly improve the accuracy of the prediction of the upper limit of program resource consumption.
[0071] The above is only a preferred embodiment of the present invention, and does not limit the present invention in any form. Although the present invention has been disclosed as a preferred embodiment, it is not intended to limit the present invention. Therefore, any simple modification, equivalent change and modification made to the above embodiment according to the technical essence of the present invention without departing from the content of the technical solution of the present invention shall fall within the scope of protection of the technical solution of the present invention.
Claims
1. A method for predicting the upper bound of program resource consumption based on resource usage-aware fuzzy testing, characterized in that the steps include: Step S1, using a static analysis method to identify a resource usage operation API of a specified resource type in a target program, identify functions involving resource usage, and identify control flow branches where resource usage is located, and insert a predefined resource usage modeling function and a call statement of a coverage label function for code coverage labeling into the target program to obtain an inserted program; Step S2, using resource consumption and resource usage operation coverage as a guide, fuzz testing is performed on the instrumented program to obtain the resource consumption of the target program in the worst case, which is the predicted upper bound of program resource consumption; The steps of step S2 include: Step S201, input the instrumented program and the initial input case, initialize the currently found maximum resource consumption max_res to 0, and initialize the fuzzy test seed sequence to a queue composed of the initial input case; Step S202, executing fuzz testing, selecting an input from the fuzz testing seed sequence and mutating it each time, generating a mutated input, running the mutated input and monitoring the execution status, collecting resource usage information and resource usage perception coverage information, and obtaining the maximum resource consumption of the current execution after the execution ends; Step S203, determine the maximum value of the resource consumption of the current execution, if it is greater than the currently found maximum resource consumption max_res, assign the maximum value of the resource consumption of the current execution to the currently found maximum resource consumption max_res, and add it to the fuzz test seed sequence to continue to apply mutation to generate test cases; or if the resource usage position that was not covered before is covered during the execution of the current mutated input, add the current mutated input to the seed sequence; Step S204, determine whether the execution of the current input will cause the program to crash. If so, add the current input to the test case set BuggyS that collects and triggers resource usage errors. After completing the fuzz test of the current input, obtain the maximum value of resource consumption within a given time and the test case set BuggyS that triggers resource usage errors and output them.
2. The method for predicting the upper bound of program resource consumption based on resource usage-aware fuzzy testing according to claim 1, characterized in that: The step S1 comprises: Step S101, identifying a resource usage operation API: the resource usage operation API includes an application programming interface provided by a system or library, and an application programming interface defined in an application. For the resource usage operation, a corresponding resource usage modeling function is defined, and the resource usage modeling function is inserted into a specified position in a target program, and resource usage is modeled by explicitly calling the resource usage modeling function in the target program; Step S102, identifying functions involved in resource usage: according to the resource usage operation API obtained in step S101 and the function call graph of the target program, identifying a list of all functions that directly or indirectly call the resource usage operation, and inserting a preset coverage label function before calling the position of each identified function, so as to identify the basic blocks involved in resource usage in the program; Step S103, identify the control flow branch where the resource is used: obtain all target program blocks that contain the resource usage modeling function or the coverage label function, identify the control flow branch where the target program block is located, and insert a preset coverage label function before the control flow branch where the target program block is located and at the beginning of the program block of another branch.
3. The method for predicting the upper bound of program resource consumption based on resource usage-aware fuzzy testing according to claim 2, characterized in that: The resource usage modeling function includes a first modeling function __RAlloc(intn) and a second modeling function __RDealloc(intn). The first modeling function __RAlloc(intn) is used to model the allocation of resource quantity n, that is, the current resource usage res_now is added with n, wherein if the current resource usage res_now is more than the current resource usage peak res_peak, the value of the resource usage res_now is assigned to the current resource usage peak res_peak; the second modeling function __RDealloc(intn) is used to model the release of resource quantity n, that is, the current resource usage (res_now) is subtracted with n.
4. The method for predicting the upper bound of program resource consumption based on resource usage-aware fuzzy testing according to claim 2, characterized in that: The preset coverage label function is a __covl() function, that is, in the step S102, a function __covl() is inserted to identify the basic blocks involving resource usage in the program by the function __covl(), and the function __covl() is an empty function; in the step S103, a function __covl() is inserted before the control flow branch where the target program block is located and at the beginning of the program block of another branch.
5. The method for predicting the upper bound of program resource consumption based on resource usage-aware fuzzy testing according to claim 2, characterized in that: In the step S103, the preset coverage label function is inserted by adopting a bottom-up insertion method, that is, inserting from the innermost branch that meets the matching condition to the outermost branch, and the innermost branch that meets the matching condition is a branch containing a resource usage operation API.
6. The method for predicting the upper bound of program resource consumption based on resource usage-aware fuzzy testing according to any one of claims 1 to 5, characterized in that: In the step S1, a program instrumentation tool based on semantic patches is used to automatically instrument the calling statements of the resource usage modeling function and the coverage labeling function into the target program.
7. The method for predicting the upper bound of program resource consumption based on resource usage-aware fuzzy testing according to claim 1, characterized in that: In step S202, during the execution of the fuzzy test, the fuzzy test engine tracks the current resource usage of the current execution and the maximum resource consumption max_res currently found, updates the resource usage by capturing the parameters of the resource usage modeling function, and updates the current amount and historical peak amount of resource usage.
8. The method for predicting the upper bound of program resource consumption based on resource usage-aware fuzzy testing according to claim 1, characterized in that: During the fuzz testing process, the jumps between basic blocks including resource usage modeling functions and coverage labeling functions are recorded to guide the fuzz testing.
9. The method for predicting the upper bound of program resource consumption based on resource usage-aware fuzzy testing according to claim 1, characterized in that: During the fuzz testing process, the resource usage-aware fuzzer uses different branch coverage definitions, takes resource usage operations as coverage targets, and adds resource consumption as a guide. If the current input has new resource usage-aware coverage, the current input is added to the fuzz testing seed sequence for further mutation.
