Methods and apparatus for bounded model detection

Abstract

This specification provides a technical solution for bounded model detection. Using the method and apparatus provided in this specification, the application or module to be verified is uniformly denoted as the module under test. First, the call tree constructed by each verification unit corresponding to the module under test is obtained. Then, each node's corresponding first verification indicator is detected. Based on the first verification indicator, a first type of node that needs independent verification is determined. Next, the call relationships in the call tree are used to verify the first type of node, and other nodes are inlined into their corresponding call scenarios for verification. This effectively reduces the repetitive verification of complex functions and improves verification efficiency.

Description

Technical Field

[0001] This specification relates to one or more embodiments in the field of computer technology, and more particularly to methods and apparatus for bounded model detection. Background Technology

[0002] Bounded Model Checking (BMC) is a technique that verifies whether a machine language statement conforms to predetermined business logic or satisfies target attributes such as memory safety by finitely traversing the state space of the machine language. Specifically, BMC abstracts program statements in an application or module into a finite state machine, encoding the machine language statements and the attributes to be verified into SAT / SMT constraint expressions. Finally, an automatic solver is invoked to find counterexamples that violate the target attributes. Typically, the existence of counterexamples indicates that the corresponding target attribute is not satisfied. When the target attribute is related to memory safety, BMC can be used to verify whether machine language statements are memory-safe.

[0003] Because BMC (Boundary Management Confirmation) technology requires exhaustively traversing the state space of an application or module, the solution time is directly proportional to the number and complexity of the constraint expressions when calling the solver to verify the target properties. For large-scale statements in real-world applications or modules, there may be situations where functions in the enumeration path are verified multiple times. Therefore, optimizing the verification scheme and improving the verification efficiency of applications or modules is a significant technical challenge. Summary of the Invention

[0004] This specification describes one or more embodiments of a method and apparatus for bounded model detection, which addresses one or more problems mentioned in the background art.

[0005] According to the first aspect, a bounded model detection method is provided for memory safety verification of a module under test. The method includes: obtaining a call tree corresponding to the module under test, wherein a single node in the call tree corresponds to a single verification unit, a single verification unit is used to verify a single task unit in the module under test, 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 based on each first verification indicator; verifying the first type of node firstly according to the call relationship in the call tree, and then inlining other nodes to the order of verifying other nodes based on the corresponding call scenario of the call path tree, thereby completing the inspection and detection of the module under test.

[0006] In one embodiment, the call tree is constructed by: obtaining several verification paths written for the module under test, each verification path including the sequential call relationship between various verification functions; taking each verification unit as a node and constructing the call tree according to the several verification paths.

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

[0008] In one embodiment, determining the first type of node that needs to be independently verified based on each first verification indicator includes: identifying nodes whose first verification indicator is greater than the verification threshold as first type nodes.

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

[0010] In one embodiment, the step of 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: verifying the first type of nodes in the order of verifying child nodes first and then verifying parent nodes, and applying the verification results of child nodes to the verification of parent nodes; for other nodes besides the first type of nodes, inline verification is performed during the verification process of the first type of nodes.

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

[0012] According to the second aspect, a bounded model detection apparatus is provided for verifying the memory security of a module under test; the apparatus includes:

[0013] The acquisition unit is configured to acquire the call tree corresponding to the module under test. A single node in the call tree corresponds to a single verification unit. A single verification unit is used to verify a single task unit in the module under test. A single incoming edge of a single node indicates that the corresponding task unit is called once.

[0014] The 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 and the verification complexity of the corresponding node.

[0015] The unit is configured to determine the first type of node that needs to be independently verified based on each first verification indicator.

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

[0017] According to a third aspect, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method described in the first aspect.

[0018] According to a fourth aspect, a computing device is provided, including a memory and a processor, characterized in that the memory stores executable code, and when the processor executes the executable code, it implements the method described in the first aspect.

[0019] The methods and apparatus provided in the embodiments of this specification unify the applications or modules to be verified as modules under test. First, a call tree constructed based on each verification unit corresponding to the module under test is obtained. Then, each node's corresponding first verification indicator is detected. Based on the first verification indicators, a first type of node requiring independent verification is determined. Next, the call relationships in the call tree are used to verify the first type of node, and other nodes are inlined into the corresponding call scenarios for verification. Here, the method of filtering first-type nodes by fusing the number of incoming edges and verification complexity to obtain the corresponding first verification indicators for each node can effectively filter out complex verification units with a high number of repeated calls. The call tree is used to enumerate various call scenarios for independent verification and to provide verification results. Thus, following the call tree from the called task unit (callee) to the calling task unit (caller), the verification results of the called complex task unit (callee) are directly used, effectively reducing repeated verification of complex task units and improving verification efficiency. Attached Figure Description

[0020] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 A schematic diagram illustrating the process of bounded model detection according to one embodiment of this specification is shown.

[0022] Figure 2 This shows a concrete example of building a call tree based on the verification path;

[0023] Figure 3 This shows a specific example of verification based on the first type of nodes selected from the screening process;

[0024] Figure 4 A schematic block diagram of an apparatus for bounded model detection according to one embodiment of this specification is shown. Detailed Implementation

[0025] The technical solutions provided in this specification are described below with reference to the accompanying drawings.

[0026] It can be understood that BMC (Browser Computational Model) is a type of formal verification. Formal verification typically uses mathematical methods to perform rigorous logical analysis on computer statements to prove that the operations or values ​​involved in the computer statements satisfy 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 an information push service module, a privacy computing module, etc.) from which the computer statements are formed. Formal verification can be performed using verification platforms (such as Kani). Specifically, the verification platform can be used to encode the computer statements into verification statements, and according to the constraint expressions given by the verification statements (such as SAT / SMT constraint expressions), a solver can be used to find counterexamples. If no counterexamples are found, it indicates that the target property is satisfied. When the target property is a memory safety-related property, BMC can be used to verify whether the program satisfies the memory safety property.

[0027] The following are some examples of common verification schemes.

[0028] One verification scheme involves verifying all verification statements in parallel, meaning multiple verification tasks are performed simultaneously (multiple people, multiple tasks in parallel). In this approach, the same task unit (a unit that implements a predetermined function, such as a single function) may be verified multiple times if it appears in multiple verification paths.

[0029] Another verification scheme involves verifying the first task unit encountered during the verification process and recording the verification result (e.g., denoted as a stub). When the same task unit is encountered again in subsequent verification processes, the previously recorded verification result is used directly. However, in this approach, the verification result of the task unit may be based on the scenario recorded during the initial analysis, which may not comprehensively cover all possible calling scenarios, i.e., it may not list all possibilities required by the module under test. Therefore, this could lead to unreliable verification results.

[0030] In view of this, this specification provides a technical solution for bounded model detection. It identifies the call relationships between task units through the global call tree of the module under test and obtains various call scenarios for individual task units. For complex task units with a high number of calls, independent verification can be performed. Then, the existing verification results can be used to verify other functions calling this complex task unit according to the call tree. Considering that simple task units usually do not cause problems in independent calls, and even if problems occur, they are more likely to occur in specific context calls, simple task units can be inlined into complex task units for verification. When selecting task units that need independent verification, the number of calls and the complexity of the task unit can be considered comprehensively, such as by using a first verification metric 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 call scenarios, thus improving verification efficiency.

[0031] The following is combined Figure 1 The illustrated embodiments provide a detailed description of the technical concepts in this specification.

[0032] Figure 1 This document illustrates a process for bounded model detection according to one embodiment of the specification, used to verify the memory safety of a module under test. The process can be executed by any computer, device, or server with sufficient computing power.

[0033] like Figure 1 As shown in the embodiments of this specification, the bounded model detection process may include the following steps: Step 101, obtaining the call tree corresponding to the module under test, 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 based on each first verification indicator; Step 104, 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, thereby completing the detection of the module under test.

[0034] First, in step 101, the call tree corresponding to the module under test is obtained.

[0035] It's understandable that the module under test here can be an application or module that needs to be verified to implement predetermined functions. Predetermined functions can be functions determined based on business requirements, such as social functions, navigation functions, prediction functions, classification functions, calculation functions, and so on. Correspondingly, the module under test can be a social application, a navigation application, a prediction service module, a classification service module, a privacy calculation module, and so on. The object of verification can be the source code of the module under test (i.e., the machine language that implements the relevant functions).

[0036] Typically, the intended function implemented by the module under test can include multiple sub-functions, such as finding the maximum value among four numbers, or comparing the size of two numbers, and so on. A single sub-function can be implemented through a corresponding task unit (such as a function). Therefore, the intended function, as the target function, can be implemented through calls between task units. The call relationship between task units can be described by a path. As an example, to implement the function of finding the largest of four numbers, a function `Max4` can be defined as a task unit to find the largest of four numbers, and a function `Max2` can be defined as a task unit to find the larger of two numbers. The `Max4` function is called in the main function (such as the `main` function), and then another function `Max2` is called in `Max4`. By calling the `Max2` function multiple times in `Max4`, the larger of the four numbers can be found, and then this value is returned to the main function, where the result is output. Here, there exists a call path of "main function → Max4 → Max2".

[0037] During the verification process of the module under test, users can write corresponding verification statements. A single task unit can correspond to a single verification unit. A verification unit can describe the call relationships consistent with the task units in the module under test. For larger modules under test, there can be multiple call paths, and corresponding verification units can correspond to multiple verification paths. For example, a verification path can be represented as: VerifyPath i =h→f i →f j →...→f k In the form of, h is the initial verification unit, and f is the number of adjacent verification units. i and f j , is f i Call f j The relationship, f k This refers to the last verification unit called on the path. For recursive calls between task units, the number of recursive calls can be considered as 1; that is, the number of times a verification unit is called in the verification path is 1. This constructs the VerifyPath. i The number of verification units in the middle must be finite.

[0038] like Figure 2 The image shows a specific example of a verification path. Figure 2 In the example, some verification statements written for the module under test include "fn harness_1(){h1()}", "fn harness_2(){h2()}", and "fn harness_3(){h3()}". Here, h1 serves as the target verification unit (e.g., the corresponding target task unit) and is verified in harness_1. During the execution of h1, verification units such as f1 and f2 are executed, and f1 internally calls f2. Therefore, 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. Based on the calling relationship of the verification units, there are three verification paths: h1→f1→f2→..., h2→f2→f3→..., and h3→f3→f4→....

[0039] Thus, a call tree (also called a call tree, denoted as calltree) can be constructed based on the call relationship. The call tree is used to describe the call relationship between verification units, and each node in it corresponds one-to-one with 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 that node. It can be understood that since there is a call and called relationship between nodes, the edges can be directed edges, and the call is described by the direction of the edge. In this specification, the incoming edge can represent the task unit corresponding to the corresponding node being called, but it is not excluded that in practice, the corresponding task unit can be called by other directed edges (such as outgoing edges). 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 case, then there are two directed edges from node A to node B.

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

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

[0042] It's understandable that if a node has many incoming edges, it indicates that the corresponding task unit has been called multiple times across all verification paths. If all paths are verified indiscriminately, the corresponding verification unit will be repeatedly executed by the BMC. Based on the technical concept outlined in this specification, we can consider independently verifying the verification units corresponding to task units with high call counts to obtain the corresponding verification results. When verifying their parent nodes, the corresponding verification results can be directly used, thereby improving the overall verification efficiency.

[0043] Here, independent verification and inline verification are corresponding concepts. Inline verification means that when executing the corresponding verification unit, the verification units corresponding to the corresponding child nodes are also executed to perform verification. Independent verification, on the other hand, performs verification separately and obtains the verification result, which can be directly used when executing the parent node verification.

[0044] However, for some logically simple functions, such as summation functions, problems are usually not caused in independent calls; even if problems do occur, they are more likely to occur in a specific calling context. If these functions are all screened out and verified independently, the burden of verification work may increase and the verification efficiency may decrease due to the need to exhaustively enumerate all possible scenarios.

[0045] Therefore, the embodiments of this specification can comprehensively consider the number of incoming edges (i.e., the number of times it is called) of the corresponding node and the complexity of the verification unit, and measure the verification complexity of the corresponding task unit by using the verification index (such as the first verification index) obtained by fusing the number of incoming edges of the corresponding node and the verification complexity. Based on the verification complexity, it can be determined whether the corresponding verification unit needs to be executed independently.

[0046] Verification complexity measures the complexity of a verification unit (e.g., the function complexity of function f is denoted as cmplx(f)). It can be obtained through at least one of cognitive complexity or cyclomatic complexity. Cognitive complexity is determined by examining the form of the verification unit. For example, it can be determined by examining factors such as the statement length, operation type, and the number of operations of different types within the verification unit. Under the same conditions, the longer the statement, the more operation types, or the more operands of different types, the higher the cognitive complexity. Cyclic complexity measures the logical complexity of the statement, also known as control flow complexity. Cyclic complexity is determined by calculating the control flow branches (e.g., if / else branches, loop branches) within the corresponding verification unit. For example, one way to calculate cyclomatic complexity is: m - n + 2p, where m is the number of edges within the verification unit, n is the number of vertices within the verification unit, and p is the number of connected components within the verification unit. When the verification complexity is obtained from multiple factors such as cognitive complexity and cyclic complexity, the various complexities can be weighted and combined. The weights of each factor can be set based on human experience.

[0047] The first verification metric for a single node can be positively correlated with both the number of incoming edges and the verification complexity of that node. Thus, in one embodiment, the first verification metric for a single node can be determined by a weighted sum of the number of incoming edges and the verification complexity of that node, denoted as verification_complexity(f) = a*Invk(f) + b*cmplx(f). Here, Invk(f) represents the number of incoming edges of the node corresponding to verification unit f, and cmplx(f) represents the verification complexity of verification unit f. The weighting can be preset. In another embodiment, the first verification metric for a single node can be determined by the product of the number of incoming edges and the verification complexity of that node, denoted as verification_complexity(f) = Invk(f)*cmplx(f).

[0048] In other embodiments, the first verification metric can also be determined in other ways, which will not be elaborated here. Thus, each first verification metric corresponding to each node can be determined. It is understood that when a node has a parent node, the verification complexity of the parent node is always no less than the verification complexity of the node itself. This is because the parent node has a calling relationship with its child nodes, and the verification of the parent node includes the verification of the child nodes.

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

[0050] Here, the first type of node refers to the node corresponding to the task unit that needs to be independently verified, as mentioned earlier. As described above, the larger the value of the first verification indicator, the more likely it is to affect the overall verification efficiency, and therefore, under the technical concept of this specification, it needs to be selected for independent verification. Here, the nodes that need to be independently verified can be denoted as the first type of node.

[0051] In one possible design, a predetermined number of nodes, ranked from highest to lowest according to the first verification metric, can be selected as the first type of nodes. The predetermined number can be a fixed value set in advance, such as 1000, or 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 validation metric is greater than the validation threshold can be selected as the first type of nodes. The validation threshold can be a predetermined threshold or determined based on the harmonic mean of the first validation metrics for each node; this is not limited here. Taking the harmonic mean as an example, the validation threshold can be the reciprocal of the sum of the reciprocals of the first validation metrics, such as: 1 / (1 / v1 + 1 / v2 + ... + 1 / v...). n ), where n is the total number of nodes in the call tree.

[0053] In many other possible designs, the first type of node can also be determined using the first verification metric through various other reasonable methods, which will not be listed here.

[0054] Typically, when a node is identified as a Class I node, all its parent nodes at each level are also identified as Class I nodes.

[0055] Then, in step 104, the first type of node is 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 under test.

[0056] For verification units with a calling relationship, the called task unit (callee) can be verified first. The return data of the called task unit can be used as a reference for the verification of the calling task unit (caller). For example, in "void f(int a,int b){g(a,b);}", task unit f calls task unit g. Then g, as the callee, is verified first, and f, as the task unit calling g, uses g's verification result for verification. That is, the verification unit corresponding to the task unit as the callee is executed first, followed by the verification unit corresponding to the task unit as the caller. In this way, leaf nodes 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, verification can be started from the leaf nodes of the call tree. In other words, if a leaf node exists that is a first-class node, it is verified first. If no leaf node exists that is a first-class node, the first-class nodes in the parent node hierarchy of the leaf node are verified first, and so on, with the first-class nodes closest to the leaf node being verified first. For a first-class node, all its call scenarios in the module under test can be exhaustively enumerated and verified to obtain verification results (such as stubs). Then, based on the call relationships indicated by the call tree, its parent node is verified. When verifying its parent node, the verification results of the first-class nodes that are its children are directly used.

[0057] For example, if task unit f calls task unit g, and the nodes corresponding to both f and g are determined to be of the first type, then 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-type node, but the node corresponding to f is determined to be a first-type node, then when verifying task unit f, task unit g is inlined into the calling scenario of f and verified together. This continues until the root node is finally verified.

[0058] Figure 3 Shown Figure 2 The diagram illustrates a specific example of the verification process corresponding to the call tree. Since f1, f2, and f3 all correspond to the first type of node, according to the technical concept of this specification, the first type of node f3 is verified first, yielding 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 f2's parent node f1 is verified, the verification result f2_stub is directly used, ultimately completing the verification of f1 and obtaining the verification result f1_stub. This process continues in the same manner.

[0059] Assume the time cost of performing verification according to the call relationship using conventional techniques is denoted as T.Non-Stubbing Then we have: The time cost of the bounded model detection scheme provided in the embodiments of this specification is denoted as T. Inter-Proc Then there is Among them, F sche F is the first type of node set mentioned earlier. exam Let T be the set of all functions in the function to be tested that have been verified by BMC. Then the improvement in verification efficiency can be denoted as: δ(T) Non-Stubbing -T Inter-Proc ) / T Non_Stubbing .

[0060] Reviewing the above process, the bounded model detection technology provided in this specification constructs a call tree based on each verification unit that verifies each task unit in the module to be verified. It then comprehensively evaluates the complexity of each verification unit in the verification task based on the call relationships in the verification path, and measures this complexity using a first verification metric. This allows for the identification of functions that require independent verification, reducing redundant verification and significantly improving 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 calling context, ensuring the correctness (sound) of the verification results. This approach balances verification efficiency and the reliability of verification results.

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

[0062] The construction unit 401 can be configured to build a call tree for the module under test, wherein a single node in 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 under test. 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 nodes that need to be verified independently based on each first verification indicator. The verification unit 404 can be configured to verify the first type of nodes according to the call relationship in the call tree, and inline other nodes to the corresponding call scenario for verification, thereby completing the detection of the module under test.

[0063] In one embodiment, the call tree can be constructed as follows: obtain several verification paths written for the module under test, each verification path including the sequential call relationship between various verification units; take each verification unit as a node and construct the call tree according to the several verification paths.

[0064] In one embodiment, the first verification metric 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 cyclic complexity of the corresponding verification unit.

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

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

[0067] In one embodiment, the verification unit 404 may be further configured to: verify the first type of nodes in the order of verifying child nodes first and then verifying parent nodes, and apply the verification results of the child nodes to the verification of the parent nodes; for other nodes besides the first type of nodes, perform inline verification 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 noting that, Figure 4 The device 400 shown is Figure 1 The described method and process correspond to this. Figure 1 The corresponding descriptions in the illustrated method embodiments also apply to apparatus 400, and will not be repeated here.

[0070] According to another embodiment, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed in a computer, causes the computer to perform a combination Figure 1 The methods described above.

[0071] According to another embodiment, a computing device is also provided, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, it implements a combination... Figure 1 The methods described above.

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

[0073] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the technical concept in this specification. It should be understood that the above description is only a specific embodiment of the technical concept in this specification and is not intended to limit the scope of protection of the technical concept in this specification. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solutions of the embodiments in this specification should be included within the scope of protection of the technical concept in this specification.

Claims

1. A bounded model detection method for verifying the memory safety of a module under test; the method includes: Obtain the call tree corresponding to the module under test. Each node in the call tree corresponds to a single verification unit. Each verification unit is used to verify a single task unit in the module under test. A single incoming edge of a single node indicates that the corresponding task unit is called once. Each node is tested for its corresponding first verification index, where a single first verification index is obtained by fusing the number of incoming edges and the verification complexity of the corresponding node. The first type of nodes that need to be independently verified are determined based on each primary verification indicator. Verify the first type of node according to the call relationship in the call tree, and inline other nodes to the corresponding call scenario for verification, thereby completing the detection of the module under test.

2. The method as described in claim 1, wherein, The call tree is constructed in the following way: Obtain several verification paths written for the module under test. Each verification path includes the sequential call relationship between each verification unit. Each verification unit is treated as a node, and a call tree is constructed based on the aforementioned verification paths.

3. The method as described in claim 1, wherein, The first verification metric is the product of the number of incoming edges of the corresponding node and the verification complexity, wherein the verification complexity is determined by the weighted sum of the cognitive complexity and cyclic complexity of the corresponding verification unit.

4. The method of claim 1, wherein, The first type of nodes that need to be independently verified based on each first verification indicator includes: Nodes whose first verification metric is greater than the verification threshold are identified as first-class nodes.

5. The method of claim 4, wherein, The verification threshold is the harmonic average of each of the first verification indicators.

6. The method of claim 1, wherein, The step of verifying the first type of node according to the call relationship in the call tree, and inlining other nodes to the corresponding call scenario for verification, includes: First-class nodes are verified in the order of verifying child nodes first and then verifying parent nodes, and the verification results of child nodes are applied to the verification of 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 apparatus for verifying the memory correctness of a module under test; the apparatus comprising: The acquisition unit is configured to acquire the call tree corresponding to the module under test. A single node in the call tree corresponds to a single verification unit. A single verification unit is used to verify a single task unit in the module under test. A single incoming edge of a single node indicates that the corresponding task unit is called once. The 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 and the verification complexity of the corresponding node. The unit is configured to determine the first type of node that needs to be independently verified based on each first verification indicator. The verification unit is configured to verify the first type of node according to the call relationship in the call tree, and to inline other nodes to the corresponding call scenario for verification, thereby completing the detection of the module under test.

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

10. A computing device, comprising a memory and a processor, characterized in that, The memory stores executable code, and when the processor executes the executable code, it implements the method of any one of claims 1-7.

Images