Method and device for bounded model detection

Abstract

According to the technical scheme of bounded model detection, through the method and device provided by the embodiment of the specification, applications or modules needing to be verified are uniformly marked as to-be-detected modules, calling trees constructed by verification units corresponding to the to-be-detected modules are firstly obtained, first verification indexes corresponding to nodes are detected, and the first verification indexes are obtained; determining a first type of nodes needing independent verification according to the first verification index, then calling the calling relation in the tree to verify the first type of nodes, and inline other nodes to corresponding calling scenes for verification. Therefore, repeated verification of complex functions can be effectively reduced, and verification efficiency is improved.

Description

Technical Field

[0001] One or more embodiments of the present specification relate to the field of computer technology, and in particular, to a method and apparatus for bounded model detection. Background Art

[0002] Bounded Model Checking (BMC) is a technology that verifies compliance with predetermined business logic and whether target properties such as memory safety are met by traversing the state space of machine language in a limited manner. Specifically, BMC technology can abstract program statements in applications or modules into finite state machines, thereby encoding machine language statements and properties to be verified as SAT / SMT constraint expressions, and finally calling the automatic solver to solve counterexamples that violate the target properties. Usually, when a counterexample exists, it indicates that the corresponding target property is not met. When the target property is related to memory safety, BMC technology can be used to verify whether the machine language statement is memory safe.

[0003] Since BMC technology needs to exhaustively traverse the state space of the application or module, when calling the solver to solve the expression to verify the target attribute, the solution time is positively correlated with the number and complexity of the constraint expression. For large-scale statements in real applications or modules, there may be situations where functions in the enumeration path are checked multiple times. Therefore, how to optimize the verification scheme and improve the verification efficiency of applications or modules is a relatively important technical issue. Summary of the invention

[0004] One or more embodiments of this specification describe a bounded model checking method and apparatus to solve one or more problems mentioned in the background technology.

[0005] According to a first aspect, a method for bounded model detection is provided, which is used to perform memory security verification on a module to be tested; the method comprises: obtaining a call tree corresponding to the module to be tested, wherein a single node on the call tree corresponds to a single verification unit, and the single verification unit is used to verify a single task unit in the module to be tested, and a single incoming edge of a single node indicates that the corresponding task unit is called once; detecting each first verification indicator corresponding to each node, wherein a single first verification indicator is obtained by fusing the number of incoming edges of the corresponding node and the verification complexity; determining a first type of node that needs to be independently verified according to each first verification indicator; first verifying the first type of node according to the calling relationship in the call tree, and then inlining other nodes to the order of verifying other nodes based on the corresponding calling scenarios of the call path tree, thereby completing the inspection and detection of the module to be tested.

[0006] In one embodiment, the call tree is constructed in the following manner: obtaining several verification paths written for the module to be tested, a single verification path including the sequential calling relationship between various verification functions; taking each verification unit as each node, and constructing the call tree according to the several verification paths.

[0007] In one embodiment, the first verification index is the product of the number of incoming edges of the corresponding node and the verification complexity, and the verification complexity is determined by the weighted sum of the cognitive complexity and the loop complexity of the corresponding verification unit.

[0008] In one embodiment, determining the first type of nodes that need to be independently verified according to each first verification index includes: determining the nodes whose first verification index is greater than a verification threshold as the first type of nodes.

[0009] In a further embodiment, the verification threshold is a harmonic mean of the first verification indicators.

[0010] In one embodiment, verifying the first type of nodes according to the calling relationship in the call tree and inlining other nodes into the corresponding calling scenario for verification includes: verifying the first type of nodes in the order of verifying the child nodes first and then the parent nodes, and applying the verification results of the child nodes to the verification of the parent nodes; for other nodes outside the first type of nodes, inline verification is performed during the verification of the first type of nodes.

[0011] In an embodiment, in the call tree, when a single task unit is recursively called, the recursive call corresponds to one incoming edge of the corresponding node.

[0012] According to a second aspect, a bounded model checking device is provided, which is used to perform memory security verification on a module to be tested; the device comprises:

[0013] An acquisition unit is configured to acquire a call tree corresponding to the module to be tested, wherein a single node on the call tree corresponds to a single verification unit, and a single verification unit is used to verify a single task unit in the module to be tested, and a single incoming edge of a single node indicates that the corresponding task unit is called once;

[0014] A detection unit is configured to detect each first verification indicator corresponding to each node, wherein a single first verification indicator is obtained by fusing the number of incoming edges of the corresponding node and the verification complexity;

[0015] A determination unit, configured to determine the first type of nodes that need to be independently verified according to each first verification indicator;

[0016] The verification unit is configured to verify the first type of nodes according to the call relationship in the call tree, and inline other nodes into the corresponding call scenario for verification, thereby completing the detection of the module to be tested.

[0017] According to a third aspect, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed in a computer, the computer is caused to execute the method described in the first aspect.

[0018] According to a fourth aspect, a computing device is provided, comprising a memory and a processor, wherein an executable code is stored in the memory, and when the processor executes the executable code, the method described in the first aspect is implemented.

[0019] Through the method and device provided in the embodiments of this specification, the application or module that needs to be verified is uniformly recorded as a module to be tested, and the call tree constructed according to each verification unit corresponding to the module to be tested is first obtained, and each first verification indicator corresponding to each node is detected. The first type of node that needs to be independently verified is determined according to the first verification indicator, and then the call relationship in the call tree is used to verify the first type of node, and other nodes are inlined to the corresponding call scenario for verification. Here, the method of screening the first type of nodes by obtaining each first verification indicator corresponding to each node by fusion of the number of input edges and the verification complexity can effectively screen out complex verification units with a large number of repeated calls, and use the call tree to enumerate various call scenarios for independent verification and give verification results, so that according to the call tree from the called task unit (callee) to the calling task unit (caller), the verification result of the called complex task unit (callee) is directly used, thereby effectively reducing the repeated verification of complex task units and improving verification efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0021] Figure 1 A schematic diagram showing a process of bounded model detection according to an embodiment of the present specification is shown;

[0022] Figure 2 A specific example of building a call tree based on a verification path is shown;

[0023] Figure 3 A specific example of performing verification based on the screened first type of nodes is shown;

[0024] Figure 4 A schematic block diagram of a bounded model detection device according to an embodiment of the present specification is shown. DETAILED DESCRIPTION

[0025] The technical solution provided in this specification is described below in conjunction with the accompanying drawings.

[0026] It can be understood that BMC is a type of formal verification. Formal proof can usually use mathematical methods to perform rigorous logical analysis on computer statements to prove that the operations or values ​​involved in the computer statements meet predetermined properties, specifications, etc. This often involves a comprehensive enumeration and deduction of the variable value space and path space of the application or module (such as information push service module, privacy computing module, etc.) formed by the computer statement. Formal proof can be performed through a verification platform (such as Kani, etc.). Specifically, the verification platform can be used to encode computer statements into verification statements, and according to the constraint expression given by the verification statement (such as SAT / SMT constraint expression), the solver is used to solve the counterexample. In the absence of a counterexample, it indicates that the target attribute is satisfied. When the target attribute is a memory safety-related attribute, BMC can be used to verify whether the program satisfies the memory safety attribute.

[0027] The following are some common verification schemes.

[0028] One verification scheme, for example, is to verify all verification statements. The verification method can be parallel, that is, multiple verification tasks are performed simultaneously (multiple people, multiple tasks in parallel). In this way, if the same task unit (a unit that implements a predetermined function, such as a single function) appears in multiple verification paths, it may be verified multiple times.

[0029] Another verification scheme is, for example, to verify the task unit encountered for the first time during the verification process, and record its verification result (such as stub). When the same task unit is encountered again in a subsequent verification process, the previously recorded verification result is directly used. Under this method, the verification result of the task unit may be recorded based on the scenario during the first analysis, so it may not fully cover all possible calling scenarios, that is, it may not cite all the possibilities required by the module to be tested. Therefore, the verification result may be unreliable (unsound).

[0030] In view of this, the present specification provides a technical solution for bounded model detection, which finds the calling relationship between task units through the global call tree (calltree) of the module to be tested, and can obtain various calling situations of a single task unit. For complex task units with a large number of calls, independent verification can be performed. Afterwards, the existing verification results can be used to verify other functions that call the complex task unit according to the call tree. Considering that simple task units usually do not cause problems in independent calls, even if problems occur, they are more likely to occur in specific context calls. Therefore, simple task units can be inlined into complex task units for verification. When screening task units that need to be independently verified, the number of calls and the complexity of the task units can be comprehensively considered, such as by measuring the first verification index obtained by fusing the number of calls and the complexity of the task unit. In this way, the number of verifications can be reduced as much as possible while covering various calling situations, and the verification efficiency can be improved.

[0031] Combine the following Figure 1 The illustrated embodiments describe the technical concept of the present specification in detail.

[0032] Figure 1 The process of bounded model checking according to an embodiment of the present specification is shown, which is used to check the memory security of the module to be tested. The execution subject of the process can be any computer, device, or server with certain computing power.

[0033] like Figure 1 As shown, the process of bounded model detection provided by the embodiment of this specification may include the following steps: Step 101, obtaining a call tree corresponding to the module to be tested, wherein a single node on the call tree corresponds to a single task unit, and a single incoming edge of a single node indicates that the corresponding task unit is called once; Step 102, detecting each first verification indicator corresponding to each node, wherein a single first verification indicator is obtained by fusing the number of incoming edges of the corresponding node and the complexity of the task unit; Step 103, determining the first type of nodes that need to be independently verified according to each first verification indicator; Step 104, verifying the first type of nodes according to the calling relationship in the call tree, and inlining other nodes to the corresponding calling scenario for verification, thereby completing the detection of the module to be tested.

[0034] First, in step 101, a call tree corresponding to the module to be tested is obtained.

[0035] It can be understood that the module to be tested here can be an application or module that needs to be verified and is used to implement a predetermined function. The predetermined function can be a function determined according to business needs, such as a social function, a navigation function, a prediction function, a classification function, a calculation function, etc. The corresponding module to be tested can be a social application, a navigation application, a prediction service module, a classification service module, a privacy computing module, etc. The processing object targeted by the verification can be the source code of the module to be tested (i.e., the machine language that implements the relevant functions).

[0036] Usually, the predetermined function implemented by the module to be tested may include multiple sub-functions, such as the function of finding the maximum value among 4 numbers, which may include the sub-function of comparing the size of two numerical values, and so on. A single sub-function may be implemented by a corresponding task unit (such as a function). Thus, the predetermined function, as a target function, may be implemented by calling between task units. The calling relationship between task units may be described by a path. As an example, in order to implement the function of finding the largest of 4 numbers, a function Max4 may be defined as a task unit to implement finding the largest of 4 numbers, a function Max2 may be defined as a task unit to implement finding the larger of two numbers, the Max4 function may be called in a main function (such as the main function), and then another function Max2 may be called in Max4. By calling the Max2 function multiple times in Max4, the larger of the 4 numbers may be found, and then it may be returned to the main function as a function value, and the result may be output in the main function. Here, there is a calling path of "main function → Max4 → Max2".

[0037] During the verification process of the module to be tested, the user can write the corresponding verification statement. A single task unit can correspond to a single verification unit. The verification unit can describe the calling relationship consistent with the task unit in the module to be tested. For a large-scale module to be tested, there can be multiple calling paths, and the corresponding verification units can correspond to multiple verification paths. For example, a verification path can be expressed as: VerifyPath i =h→f i →f j →...→f k In the form of, h is the starting verification unit, and the two adjacent verification units f i and f j , is f i Call f j The relationship between k is the last called verification unit on the path. For recursive calls between task units, the number of recursive calls can be considered to be 1, that is, the number of calls to the verification unit in the verification path is 1. The verification path VerifyPath constructed in this way i The number of verification units in must be limited.

[0038] like Figure 2 A specific example of a verification path is shown in Figure 1. Figure 2 In the example, some verification statements written for the module to be tested include, for example, "fn harness_1(){h1()}", "fn harness_2(){h2()}", and "fn harness_3(){h3()}". Among them, h1 is the target verification unit (such as the corresponding target task unit) and is verified in harness_1. During the execution of h1, verification units such as f1 and f2 are all executed, and f1 calls f2 internally, so a verification path VerifyPath=h1→f1→f2→... can be obtained. Figure 2 The verification statements shown correspond to three target verification units h1, h2, and h3 respectively. According to the calling relationship of the verification units, there can be three corresponding verification paths h1→f1→f2→..., h2→f2→f3→..., and h3→f3→f4→...

[0039] In this way, a call tree (also called a call tree, such as denoted as calltree) can be constructed according to the call relationship. The call tree is used to describe the verification unit call relationship, and each node therein can correspond one to one to each verification unit. For example, the root node can represent the main verification unit, and the child nodes of a single node can be other verification units called by the node. It can be understood that since there is a calling and called relationship between the nodes, the edges therein can be directed edges, and the calls are described by the edge direction. In this specification, the incoming edge can be used to indicate that the task unit corresponding to the corresponding node is called, but it does not rule out the possibility that other directed edges (such as outgoing edges) can be used in practice to indicate that the corresponding task unit is called. Among them, the edges between nodes are not merged. For example, if task unit a (corresponding to node A) calls task unit b (corresponding to node B) twice in a non-recursive call, there are two directed edges corresponding to node A pointing to node B.

[0040] In an optional embodiment, when constructing a call tree, if there is a recursive call of a task unit, the recursive call may correspond to one incoming edge of the corresponding node. In other words, if a single task unit is recursively called, the total number of calls of the task unit in the recursive call is recorded as 1.

[0041] Then, according to step 102, each first verification indicator corresponding to each node is detected.

[0042] It can be understood that if a node has many incoming edges, it means that the corresponding task unit has been called multiple times in all verification paths. If each path is verified indiscriminately, the corresponding verification unit will be repeatedly verified by the BMC. Under the technical concept of this specification, it can be considered to independently verify the verification unit corresponding to the task unit with a large number of calls to obtain the corresponding verification result. When verifying its parent node, the corresponding verification result can be used directly, thereby improving the efficiency of the overall verification.

[0043] Here, independent verification and inline verification are corresponding concepts. Inline verification means that when executing the corresponding verification unit, the verification unit corresponding to the corresponding child node is executed together for verification, while independent verification is to perform separate verification and obtain the verification result, which can be directly used when executing parent node verification.

[0044] However, for some functions with simpler logic, such as summation functions, independent calls usually do not cause problems; even if problems occur, they are more likely to occur in a specific calling context. For these functions, if they are all screened out for independent verification, in order to exhaust various situations, the verification workload may increase and the verification efficiency may be reduced.

[0045] To this end, the embodiments of the present specification can comprehensively consider the number of incoming edges of the corresponding node (i.e., the number of times it is called) and the complexity of the verification unit, and measure the verification complexity of the corresponding task unit through the verification index (such as recorded as the first verification index) obtained by fusing the number of incoming edges of the corresponding node and the verification complexity, so as to determine whether the corresponding verification unit needs to be independently verified based on the verification complexity.

[0046] Among them, verification complexity can be used to measure the complexity of the verification unit (such as the function complexity of function f is recorded as cmplx(f)), which can be obtained by at least one of cognitive complexity, cyclomatic complexity, etc. Cognitive complexity is determined by detecting the form of the verification unit. For example, it is determined by detecting factors such as the statement length, operation type, and the number of different types of operations of the verification unit. Under the same conditions, the longer the statement length, or the more operation types, or the more different types of operations, the higher the cognitive complexity. Cyclic complexity measures the logical complexity of the statement, or is called control flow complexity. Cyclic complexity determines the corresponding complexity by calculating the control flow branches (such as if / else branches, loop branches) inside the corresponding verification unit. For example, a calculation method for cyclomatic complexity is: m-n+2p, where m is the number of edges inside the verification unit, n is the number of vertices inside the verification unit, and p is the number of connected branches inside the verification unit. When the verification complexity is obtained through multiple factors such as cognitive complexity, loop complexity, etc., each complexity factor can be weighted and integrated, and the weight of each factor can be set according to manual experience.

[0047] The first verification index corresponding to a single node can be positively correlated with the number of incoming edges and the verification complexity of the corresponding node. Thus, in one embodiment, the first verification index corresponding to a single node can be determined by the weighted sum of the number of incoming edges and the verification complexity of the corresponding node, such as recorded as verification_complexity(f)=a*Invk(f)+b*cmplx(f). Among them, Invk(f) represents the number of incoming edges of the node corresponding to the verification unit f, and cmplx(f) represents the verification complexity of the verification unit f. At this time, the weighted weight can be pre-set. In another embodiment, the first verification index corresponding to a single node can be determined by the product of the number of incoming edges of the corresponding node and the verification complexity, such as recorded as verification_complexity(f)=Invk(f)*cmplx(f).

[0048] In other embodiments, the first verification indicator can also be determined by other methods, which will not be described one by one here. Thus, the first verification indicators corresponding to each node can be determined. It can be understood that when a node corresponds to a parent node, the verification complexity of the parent node of the node must be no less than the verification complexity of the node. This is because the parent node has a calling relationship with the child node, and the verification of the parent node includes the verification of the child node.

[0049] Next, through step 103, the first type of nodes that need to be independently verified are determined according to each first verification indicator.

[0050] Here, the first type of node is the node corresponding to the task unit that needs independent verification mentioned above. According to the description above, the larger the value of the first verification indicator, the more likely it is to affect the overall verification efficiency, and under the technical concept of this specification, the more it needs to be screened out for independent verification. Here, the nodes that need independent verification can be recorded as the first type of nodes.

[0051] In a possible design, a predetermined number of nodes ranked top in descending order of the first verification index may be selected as the first type of nodes, wherein the predetermined number may be a preset fixed value, such as 1000, or may be a number corresponding to a predetermined proportion of the total number of nodes, such as 20% of the total number of nodes, and so on.

[0052] In another possible design, nodes whose first verification index is greater than the verification threshold can be selected as first-class nodes. The verification threshold can be a predetermined threshold or can be determined based on the harmonic mean of the first verification indexes corresponding to the nodes, which is not limited here. Taking the harmonic mean as an example, the verification threshold can be the reciprocal of the sum of the reciprocals of the first verification indexes, such as: 1 / (1 / v1+1 / v2+…1 / v n ), n is the total number of nodes in the call tree.

[0053] In more possible designs, the first type of nodes can be determined using the first verification indicator in various other reasonable ways, which are not listed here one by one.

[0054] Generally, when a node is confirmed as a first-class node, its parent nodes at all levels are confirmed as first-class nodes.

[0055] Furthermore, in step 104, the first type of nodes are verified according to the call relationship in the call tree, and other nodes are inlined to the corresponding call scenario for verification, thereby completing the detection of the module to be tested.

[0056] For the verification units with a calling relationship, the called task unit (callee) can be verified first, and the return data of the called task unit can be used as a reference for the verification of the task unit (caller) that calls it. For example, in "void f(int a,int b){g(a,b);}", task unit f calls task unit g, then g is verified first as the callee, and f, as the task unit that calls g, uses the verification result of g to verify. In other words, the verification unit corresponding to the task unit as the callee is executed first, and then the verification unit corresponding to the task unit as the caller is executed. In this way, the leaf node can be used as the final callee for priority verification. For the first type of node, since it cannot be inlined to other nodes for verification, and the verification of the parent node requires the verification result of the child node, it is possible to start verification from the leaf node of the call tree first. That is to say, in the case where there is a leaf node that is a first-class node, the leaf node that is a first-class node is verified first. In the case where there is no leaf node that is a first-class node, the node that is a first-class node in the parent node level of the leaf node is verified first... and so on, limited verification of the first-class nodes close to the leaf nodes. For the first-class node, all its calling scenarios in the module to be tested can be obtained and verified exhaustively to obtain the verification result (such as stub). Afterwards, based on the calling relationship indicated by the call tree, its parent node is verified. When verifying its parent node, the verification result of the first-class node as a child node is directly used.

[0057] For example, when task unit f calls task unit g, and the nodes corresponding to f and g are both determined to be first-class nodes, g is verified first, and the verification result is used to verify f. If the node corresponding to g is not determined to be a first-class node, but the node corresponding to f is determined to be a first-class node, when verifying task unit f, task unit g is inlined to the calling scenario of f and verified together. This process continues until the root node is finally verified.

[0058] Figure 3 Shown Figure 2 The illustrated verification process diagram of a specific example of the call tree. After detection, f1, f2, and f3 all correspond to the first type of nodes. Under the technical concept of this specification, the first type of node f3 is first verified to obtain the verification result f3_stub. When its parent node f2 is verified, the verification result f3_stub is directly used to obtain the verification result f2_stub. When the parent node f1 of f2 is verified, the verification result f2_stub is directly used, and finally the verification of f1 is completed to obtain the verification result f1_stub. And so on.

[0059] Assume that the time cost of verifying the call relationship using conventional technology is recorded as TNon-Stubbing , then: According to the bounded model detection solution provided in the embodiment of this specification, the time cost is denoted as T Inter-Proc , then Among them, F sche is the first type of node set mentioned above, F exam is the set of all functions verified by BMC in the tested functions. Then the verification efficiency improvement can be recorded as: δ(T Non-Stubbing -T Inter-Proc ) / T Non_Stubbing .

[0060] Reviewing the above process, the technical concept of bounded model detection provided by the embodiment of this specification builds a call tree according to each verification unit that verifies each task unit in the module to be verified, and comprehensively evaluates the complexity of each verification unit in the verification task based on the call relationship in the verification path, and measures it through the first verification index, thereby dividing out some functions that need to be independently verified to reduce repeated verification and significantly improve the overall verification efficiency of the module to be verified. For independently verified task units, the corresponding verification units are executed independently, and their verification results are used to replace their call contexts to ensure the correctness of the verification results (sound). This processing method takes into account both verification efficiency and the reliability of verification results.

[0061] According to another embodiment, a bounded model detection device is also provided. The bounded model detection device can be set in a computer, device or server with a certain computing power to check the memory security of the module to be tested. Figure 4 As shown, the bounded model detection apparatus 400 may include a construction unit 401 , a detection unit 402 , a determination unit 403 , and a verification unit 404 .

[0062] Among them, the construction unit 401 can be configured to construct a call tree for the module to be tested, wherein a single node on the call tree corresponds to a single verification unit, and the single verification unit is used to verify a single task unit in the module to be tested, and a single incoming edge of a single node indicates that the corresponding task unit is called once; the detection unit 402 can be configured to detect each first verification indicator corresponding to each node, wherein a single first verification indicator is obtained by fusing the number of incoming edges of the corresponding node and the verification complexity; the determination unit 403 can be configured to determine the first type of node that needs to be independently verified according to each first verification indicator; the verification unit 404 can be configured to verify the first type of node according to the calling relationship in the call tree, and inline other nodes into the corresponding calling scenario for verification, thereby completing the detection of the module to be tested.

[0063] In one embodiment, the call tree can be constructed in the following manner: obtain several verification paths written for the module to be tested, a single verification path includes the sequential calling relationship between various verification units; use each verification unit as a node, and construct a call tree according to the several verification paths.

[0064] In one embodiment, the first verification index is the product of the number of incoming edges of the corresponding node and the verification complexity, and the verification complexity is determined by the weighted sum of the cognitive complexity and the loop complexity of the corresponding verification unit.

[0065] In one embodiment, the determining unit 403 may be further configured to: determine a node whose first verification index is greater than a verification threshold as a first-category node.

[0066] In a further embodiment, the verification threshold is a harmonic mean of the first verification indicators.

[0067] In one embodiment, the verification unit 404 can be further configured to: verify the first type of nodes in the order of verifying the child nodes first and then the parent nodes, and apply the verification results of the child nodes to the verification of the parent nodes; for other nodes outside the first type of nodes, inline verification is performed during the verification process of the first type of nodes.

[0068] In one embodiment, in the call tree, when a single task unit is recursively called, the recursive call corresponds to one incoming edge of the corresponding node.

[0069] It is worth mentioning that Figure 4 The device 400 shown is Figure 1 The method flow described corresponds to Figure 1 The corresponding description in the illustrated method embodiment is also applicable to the device 400 and will not be repeated here.

[0070] According to another embodiment, there is also provided a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to execute a combination of Figure 1 The method described by et al.

[0071] According to another embodiment of the present invention, a computing device is provided, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the Figure 1 The method described by et al.

[0072] Those skilled in the art should be aware that in one or more of the above examples, the functions described in the embodiments of this specification can be implemented by hardware, software, firmware, or any combination thereof. When implemented by software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or codes on a computer-readable medium.

[0073] The specific implementation methods described above further explain in detail the purpose, technical solutions and beneficial effects of the technical concept of this specification. It should be understood that the above description is only the specific implementation method of the technical concept of this specification, and is not used to limit the protection scope of the technical concept of this specification. Any modifications, equivalent substitutions, improvements, etc. made on the basis of the technical solutions of the embodiments of this specification should be included in the protection scope of the technical concept of this specification.

Claims

1. A bounded model checking method for performing memory security verification on a module to be tested; the method comprises: Get the call tree corresponding to the module to be tested, where a single node on the call tree corresponds to a single verification unit, a single verification unit is used to verify a single task unit in the module to be tested, and a single incoming edge of a single node indicates that the corresponding task unit is called once; Detecting each first verification indicator corresponding to each node, wherein a single first verification indicator is obtained by integrating the number of incoming edges of the corresponding node and the verification complexity; Determining the first type of nodes that need to be independently verified according to each first verification indicator; The first type of nodes are verified according to the call relationship in the call tree, and other nodes are inlined to the corresponding call scenario for verification, thereby completing the detection of the module to be tested.

2. The method of claim 1, wherein: The call tree is constructed in the following way: Obtain several verification paths written for the module to be tested. A single verification path includes the calling relationship between various verification units in sequence. Each verification unit is used as a node, and a call tree is constructed according to the plurality of verification paths.

3. The method of claim 1, wherein: The first verification index is the product of the number of incoming edges of the corresponding node and the verification complexity, and the verification complexity is determined by the weighted sum of the cognitive complexity and the loop complexity of the corresponding verification unit.

4. The method of claim 1, wherein: Determining the first type of nodes that need to be independently verified according to each first verification indicator includes: Nodes whose first verification index is greater than a verification threshold are determined as first-category nodes.

5. The method of claim 4, wherein: The verification threshold is the harmonic mean of each first verification index.

6. The method of claim 1, wherein: The verifying the first type of nodes according to the call relationship in the call tree and inlining other nodes to the corresponding call scenario for verification includes: Verify the first type of nodes in the order of verifying the child nodes first and then the parent nodes, and apply the verification results of the child nodes to the verification of the parent nodes; For nodes other than the first type of nodes, inline verification is performed during the verification process of the first type of nodes.

7. The method of claim 1, wherein: In the call tree, when a single task unit is recursively called, the recursive call corresponds to one incoming edge of the corresponding node.

8. A bounded model detection device, used for verifying the memory correctness of a module to be tested; the device comprises: An acquisition unit is configured to acquire a call tree corresponding to the module to be tested, wherein a single node on the call tree corresponds to a single verification unit, and the single verification unit is used to verify a single task unit in the module to be tested, and a single incoming edge of a single node indicates that the corresponding task unit is called once; A detection unit is configured to detect each first verification indicator corresponding to each node, wherein a single first verification indicator is obtained by fusing the number of incoming edges of the corresponding node and the verification complexity; A determination unit, configured to determine the first type of nodes that need to be independently verified according to each first verification indicator; The verification unit is configured to verify the first type of nodes according to the call relationship in the call tree, and inline other nodes into the corresponding call scenario for verification, thereby completing the detection of the module to be tested.

9. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to execute the method according to any one of claims 1 to 7.

10. A computing device comprising a memory and a processor, characterized in that: The memory stores executable codes, and when the processor executes the executable codes, the method according to any one of claims 1 to 7 is implemented.

Images