Operating system concurrency control C code verification system and method based on model check

Abstract

The invention discloses an operating system concurrency control C code verification system and method based on model check, and relates to the technical field of verification, the system comprises a code conversion module and a verification module; the code conversion module converts a concurrency control C code of the target operating system into a BTOR2 model, and then converts the BTOR2 model into an AIGER model; the verification module is connected with the code conversion module and calls the model inspection tool to verify the AIGER model, so that verification of the concurrency control C code of the operating system is achieved, the C code is gradually converted into the BTOR2 model and then converted into the AIGER model through the model conversion tool chain so as to be compatible with an existing model inspection tool; a traditional theorem proving method is replaced, manual intervention is reduced, verification efficiency is improved, a counter-example path can be automatically generated, and system defects can be accurately positioned; the blank that the multi-core operating system code is verified by using a model checking method is filled, and the application of a model checking technology in the field of software is expanded.

Description

Technical Field

[0001] The present invention relates to the field of verification technology, and in particular to a system and method for verifying concurrent control C code of an operating system based on model checking. Background Art

[0002] Formal methods, a key theoretical pillar of computer science, model, specify, and verify computing systems through rigorous mathematical frameworks and mechanized mechanisms, striving to eliminate potential risks in mathematical theory and software security. Based on formal logic and automated reasoning, these methods can systematically examine the behavioral properties of complex systems and identify hidden defects without relying heavily on manual intervention. With the continuous iteration of verification tools, they have been successfully applied to high-reliability scenarios such as aerospace control systems and rail transit signaling networks, effectively addressing the shortcomings of traditional simulation testing in path coverage completeness, thereby improving the fault tolerance and safety threshold of system design.

[0003] In the field of operating system security verification, the technical path shows a clear phased characteristic. Traditionally, most operating system verification technologies rely mainly on theorem proofs, ensuring system correctness through manual deduction of mathematical propositions. Although they have theoretical rigor, they expose a serious imbalance between manpower input and verification efficiency when verifying modern complex operating systems. This contradiction has driven the development of model checking technology based on automata theory. This technology achieves scalability and automation of the verification process through finite state space traversal and property determination algorithms. However, in current technical practice, model checking is still mostly focused on hardware system verification. Successful cases for software behaviors such as operating system kernel scheduling and resource allocation are still in the exploratory stage, and reusable engineering solutions have not yet been formed.

[0004] Therefore, a system and method for verifying operating system concurrency control C code based on model checking are provided to solve the above problems. Summary of the Invention

[0005] In order to solve the above problems, the present invention provides an operating system concurrency control C code verification system and method based on model checking. The operating system concurrency control C code is converted into a BTOR2 model and then converted into an AIGER model. The model checking tool is called to verify the AIGER model, thereby realizing the verification of the operating system concurrency control C code, reducing manual intervention and improving verification efficiency.

[0006] To achieve the above object, the present invention provides an operating system concurrency control C code verification system based on model checking, comprising a code conversion module and a verification module;

[0007] The code conversion module converts the target operating system concurrency control C code into the BTOR2 model, and then converts the BTOR2 model into the AIGER model;

[0008] The verification module is connected to the code conversion module and calls the model checking tool to verify the AIGER model.

[0009] Preferably, the code conversion module includes a first conversion module and a second conversion module;

[0010] The first conversion module converts the target operating system concurrency control C code into a BTOR2 model according to preset conversion rules; the conversion rules include: variable conversion rules, operator conversion rules, control structure conversion rules and concurrency control conversion rules;

[0011] The second conversion module is connected to the first conversion module to convert the BTOR2 model into the AIGER model; the BTOR2 model is input into the BTOR2AIGER converter, and corresponding output parameters are set to complete the conversion of the BTOR2 model into the AIGER model.

[0012] Preferably, the first conversion module includes a variable conversion unit, an operator conversion unit, a control structure conversion unit and a concurrency control conversion unit;

[0013] The variable conversion unit converts the variables in the target operating system concurrency control C code into variables in the BTOR2 model;

[0014] The operator conversion unit converts the operators in the concurrency control C code of the target operating system into operators in the BTOR2 model;

[0015] The control structure conversion unit converts the control structure in the concurrency control C code of the target operating system into the control structure in the BTOR2 model;

[0016] The concurrency control conversion unit converts the concurrency control mechanism in the target operating system concurrency control C code into the control mechanism in the BTOR2 model.

[0017] Preferably, the concurrency control mechanism specifically includes a semaphore mechanism and a mutex mechanism;

[0018] The semaphore mechanism manages access to shared resources. It maps semaphore operations in C code to logical constructs in BTOR2. The semaphore value is represented as a bit vector in BTOR2. The semaphore wait operation is converted to checking and updating the current semaphore value. If the semaphore value is greater than 0, the semaphore value is decremented; otherwise, the wait state is entered.

[0019] The mutex mechanism in C language involves the acquisition and release of locks. The process of acquiring a lock in the BTOR2 model is represented by conditional judgment. After successfully acquiring the lock, the state is updated. The state of the lock is modeled by state variables, and effective state management is carried out during resource access.

[0020] Preferably, the verification module includes a calling unit, a property verification unit, a counterexample searching unit, and a result output unit;

[0021] The calling unit is connected to the code conversion module and calls the AIGER model;

[0022] The property verification unit is connected to the calling unit and determines whether the target operating system satisfies specific security properties under specific conditions according to the AIGER model;

[0023] The property to be verified is P. The B sequence is used to maintain a superset of the states of!P that reach non-safe states. All states that reach!P in i steps will be in Bi. When there exists a Bi that is a subset of the union of all Bj (j < i), the model is safe. The effectiveness of the security condition indicates that the B sequence will not expand anymore. The union of B0 to Bi forms an invariant;

[0024] The counterexample searching unit is connected to the property verification unit and is used to search for counterexamples according to the output result of the property verification unit; The F sequence is a subset of the states that can be reached from the initial state I. If in a certain state space Fi, there exists a state s that belongs to the non-safe state!P, then a path starting from I and ending at state s is obtained, and this path is a counterexample of the property to be verified and will be returned;

[0025] The result output unit is connected to the property verification unit and the counterexample searching unit. After the verification is completed, according to the results of the property verification unit and the counterexample searching unit, a record verification counterexample file and a record verification information file are generated at the set output file location.

[0026] Preferably, the model checking tool includes ABC - BMC, NuSMV or SimpleCAR;

[0027] The model checking tool creates an abstract model M of a finite automaton for the operation of the system or model, creates a specification φ described in a formal language for the property to be verified, and determines whether the model M satisfies M╞φ through automatic operation. When it does not satisfy, it automatically generates a counterexample and generates a path from the initial state to the state where the property is violated.

[0028] Preferably, the BTOR2 model is converted into the AIGER model, and the following steps are specifically executed:

[0029] Call the BTOR2AIGER converter, input the BTOR2 model, generate a name from the AIG level serial number, assign a default name to the state without an explicitly associated name, set the corresponding output parameters, and complete the conversion of the BTOR2 model to the AIGER model.

[0030] A verification method for an operating system concurrent control C code verification system based on model checking specifically comprises the following steps:

[0031] S1: Convert the target operating system concurrency control C code into an AIGER model;

[0032] S2: Call ABC-BMC, NuSMV or SimpleCAR model checking tools to verify the AIGER model and obtain the verification results.

[0033] Preferably, step S1 specifically includes:

[0034] S11: converting the target operating system concurrency control C code into a BTOR2 model according to preset conversion rules; the conversion rules include: variable conversion rules, operator conversion rules, control structure conversion rules and concurrency control conversion rules;

[0035] S12: Input the BTOR2 model into the BTOR2AIGER converter, set corresponding output parameters, and complete the conversion of the BTOR2 model into the AIGER model.

[0036] Preferably, step S2 specifically includes:

[0037] S21: Input the AIGER model into the model checking tool to determine whether the verification property is established and obtain the judgment result;

[0038] S22: If the judgment result is yes, the verification is successful and the output is safe; if the judgment result is no, the verification fails and a counterexample path from the initial state to the bad state is output.

[0039] Therefore, the present invention adopts the above-mentioned operating system concurrency control C code verification system and method based on model checking, which has the following beneficial effects:

[0040] (1) This paper converts C code into an AIGER model through a multi-step conversion of the model checking format, and uses relevant model checking tools to verify the C code. The design of the model conversion and verification tool chain enables C code to be converted into the BTOR2 model and the AIGER model in sequence, thereby achieving compatibility with existing model checking tools, achieving automated verification, reducing manual intervention, and improving verification efficiency.

[0041] (2) The model checking technology in the present invention can automatically detect race conditions, data consistency problems and synchronization errors of concurrent tasks, and enhance the concurrent control analysis capability of the operating system.

[0042] (3) This invention expands the application of model checking technology at the software level, fills the gap in current multi-core operating system code verification, and improves the applicability and accuracy of verification.

[0043] (4) The present invention utilizes the counterexample path information generated by the model checking tool, so that developers can accurately locate potential security vulnerabilities and quickly repair system defects, thereby improving the robustness and security of the operating system.

[0044] The technical solution of the present invention is further described in detail below through the accompanying drawings and embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] Figure 1 This is a schematic diagram of the verification process of the model checking tool in one embodiment of the present application;

[0046] Figure 2 A schematic diagram of verification passing provided in an embodiment of the present application;

[0047] Figure 3 A schematic diagram of verification failure provided for an embodiment of the present application. DETAILED DESCRIPTION

[0048] The technical solution of the present invention is further described below with reference to the accompanying drawings and embodiments.

[0049] Unless otherwise defined, technical or scientific terms used in the present invention shall have the same meaning as commonly understood by one of ordinary skill in the art to which the present invention belongs.

[0050] The words “include” or “comprising” and similar words used in the present invention mean that the elements before the word include the elements listed after the word, and do not exclude the possibility of also including other elements. The orientation or position relationship indicated by the terms “inside”, “outside”, “upper”, “lower”, etc. is based on the orientation or position relationship shown in the accompanying drawings. It is only for the convenience of describing the present invention and simplifying the description, and does not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation. Therefore, it cannot be understood as a limitation of the present invention. When the absolute position of the described object changes, the relative position relationship may also change accordingly. In the present invention, unless otherwise clearly stipulated and limited, the terms such as “attachment” should be understood in a broad sense. For example, it can be a fixed connection, a detachable connection, or an integral whole; it can be directly connected or indirectly connected through an intermediate medium, and it can be the internal connection of two elements or the interaction relationship between two elements. For ordinary technicians in this field, the specific meanings of the above terms in the present invention can be understood according to the specific circumstances.

[0051] Example 1

[0052] A C code verification system for concurrent control of an operating system based on model checking, comprising a code conversion module and a verification module;

[0053] The code conversion module converts the target operating system concurrency control C code into the BTOR2 model, and then converts the BTOR2 model into the AIGER model;

[0054] The verification module is connected to the code conversion module and calls the model checking tool to verify the AIGER model.

[0055] The code conversion module includes a first conversion module and a second conversion module;

[0056] The first conversion module converts the target operating system concurrency control C code into a BTOR2 model according to preset conversion rules; the conversion rules include: variable conversion rules, operator conversion rules, control structure conversion rules and concurrency control conversion rules;

[0057] Taking the buffer access control code in a multi-core operating system as an example, the conversion of the target operating system concurrency control C code to the BTOR2 model is explained.

[0058] Specifically, BTOR2, as an emerging logical expression format, provides a unified representation for hardware and software. BTOR2 is a word-level model checking format used to capture hardware models and potential software models in a bit-accurate manner. BTOR2 uses design principles from the bit-level format AIGER and includes direct conversion tools for AIGER types in its toolkit. Both grammatical and semantic rules in BTOR2 are defined using the BNF paradigm. Some of the grammars in the BTOR2 verification language that support conversion in this invention include:

[0059] Variable declaration: Variables must be declared before they are used.

[0060] Data type: Supports Boolean, integer, unsigned integer and other data types.

[0061] Operators: Various operators, such as logical operators, comparison operators, arithmetic operators, etc.

[0062] Expression: Supports various forms of expressions, such as arithmetic expressions, Boolean expressions, etc.

[0063] Statement: Supports multiple statements, such as assignment statements, conditional statements, and loop statements.

[0064] Array: Supports declaration and use of arrays.

[0065] According to the syntax and semantics of BTOR2, the present invention constructs a basic conversion table with C language, as shown in Table 1, Table 2 and Table 3 below.

[0066] Table 1

[0067]

[0068]

[0069] Table 2

[0070]

[0071] Table 3

[0072]

[0073] Among them, Table 1 lists some basic data type declaration conversion methods, including integer, Boolean, array, and constant types. Table 2 lists the conversion methods of various common operators. Basically, the arithmetic, logical, and shift operators commonly used in C language have corresponding ones in BTOR2. Table 3 gives examples of loop and conditional expression conversion from C language to BTOR2: For if-else statements in C language, BTOR2's ite operator can be used to express them, and the semantics will not change. For example, in line 13, it means that if the equation in line 10 is satisfied, the addition process in line 12 is executed, otherwise the addition process in line 11 is executed. As for the loop structure, if it is an infinite loop, the statements in the loop body can be directly converted. Otherwise, a finite loop requires a loop exit condition to be added before the loop statement. As shown in the example in Table 3, lines 1-2 define a 32-bit bit vector and a 1-bit Boolean type. Lines 3-4 define two 32-bit constants: 0 (the initial value) and 5 (the upper limit of the loop). Lines 5-6 initialize j to 0. Line 7 contains the conditional expression that determines if j < 5. Line 8 uses ite to implement the conditional: if j < 5 is true, return j + 1; otherwise, return the current value. Lines 9-10 implement j++. Finally, line 11 adds a constraint to ensure that j < 5 in the loop logic, thus implementing the loop structure.

[0074] The above conversion table allows for relatively simple manual conversion of operating system C code to BTOR, for example, the access control code for buffers in an operating system. However, operating systems also have concurrent access control mechanisms, such as semaphores and mutexes. This application uses the following method to convert concurrent access control mechanisms.

[0075] Semaphores are a key mechanism for managing access to shared resources. Semaphore operations in C can be mapped to logical constructs in BTOR2. For example, a semaphore's value can be represented as a bit vector in BTOR2. Waiting on a semaphore can be converted into checking and updating the current semaphore value. If the semaphore is greater than 0, its value is decremented; otherwise, a wait state is entered. Similarly, releasing a semaphore can be represented as incrementing the semaphore's value.

[0076] Mutual exclusion locks are another common concurrency control mechanism. Their implementation in C typically involves acquiring and releasing locks. In the BTOR2 model, the lock acquisition process can be represented by conditional statements, with state updates performed upon successful lock acquisition. Lock states can be modeled using state variables, enabling efficient state management during resource access.

[0077] The second conversion module is connected to the first conversion module to convert the BTOR2 model into the AIGER model; the BTOR2 model is input into the BTOR2AIGER converter, and corresponding output parameters are set to complete the conversion of the BTOR2 model into the AIGER model.

[0078] Specifically, the AIGER format is designed specifically for hardware and can represent finite state machines and Boolean circuits in a simplified manner. BTOR2Tools provides general tools for parsing the BTOR2 format, including the BTOR2AIGER converter, which assigns default names to states that do not have explicit associated names during the conversion process. These names are generated by serial numbers at the AIG level, thereby breaking the association with the word level and ensuring that the logical expression of the model is consistent with the semantics. AIGER is a format for describing asynchronous Boolean circuits that is widely used in hardware verification and model checking, and is compatible with many hardware model checkers. BTOR2AIGER converts high-level BTOR2 models into the AIGER format to enable model checking tools to verify the security of C code.

[0079] The verification module is connected to the code conversion module and calls the model checking tool to verify the AIGER model.

[0080] Specifically, model checking is a key method in formal verification. Its key concept is to create an abstract model M of a finite automaton by running a system or model. A formal specification φ is then created for the properties to be verified. Automatic execution is then used to determine whether the model M satisfies φ, i.e., M╞φ. Model checking tools can automatically confirm whether a system satisfies specified properties through automated execution. If not, they can automatically generate counterexamples—a path from the initial state to a state where the properties are violated. This capability is extremely valuable for quickly identifying and correcting system defects.

[0081] Model checking tools often have the ability to verify properties or find counterexamples, and some model checking tools have both. Figure 1 As shown, assuming that the property to be verified is P, the algorithm maintains two sequences, sequence B and sequence F. Sequence F is a subset of states that can be reached from the initial state I. The subset indicates that all states in Fi can be reached from I in i steps, but Fi does not contain all states that can be reached from I in i steps.

[0082] The B sequence is used to maintain a superset of states that can reach the unsafe state! P. The superset indicates that all states that can reach! P in i steps will be in Bi, but there are still other states in Bi that cannot reach! P in i steps.

[0083] The reason for maintaining the subset and the superset is that both the F sequence and the B sequence are dynamic. The elements of Fi will increase continuously as the algorithm runs, and the subset will get closer and closer to the original set. While the elements of Bi will decrease continuously, and the superset will also get closer and closer to the original set.

[0084] The verification property refers to verifying whether the system satisfies a given security property under specific conditions. If there exists a Bi that is a subset of the union of all Bj (j < i), then the model is secure. The effectiveness of the security condition indicates that the B sequence will not expand anymore. Even if the B sequence continues to expand, the elements in the new Bi+1 will only be the elements that have appeared in the Bi with a smaller index. This means that the initial state I cannot reach B0, so the model is secure. At this time, the union from B0 to Bi constitutes an invariant.

[0085] On the contrary, finding a counterexample means that if there is a bad state, it can be finally searched. If there exists a state s in a certain state space Fi, and this state belongs to the non - secure state!P, then a path starting from I and ending at state s is obtained, and this path is a counterexample to the property to be verified and will be returned.

[0086] Through the model - checking algorithm that combines the verification property and finding counterexamples, the present invention can not only verify the correctness of the concurrent - control C code of the operating system, but also provide a detailed counterexample output in case of insecurity, thus providing a basis for developers to repair potential security vulnerabilities. This process effectively enhances the security of the operating system in a concurrent environment and provides important theoretical support for subsequent code optimization and design improvement.

[0087] Embodiment 2

[0088] A method for verifying the concurrent - control C code of an operating system based on model checking specifically includes the following steps:

[0089] S1: Convert the target operating - system concurrent - control C code into an AIGER model; specifically including:

[0090] S11: Convert the target operating - system concurrent - control C code into a BTOR2 model according to the preset conversion rules; the conversion rules include: variable conversion rules, operator conversion rules, control - structure conversion rules, and concurrent - control conversion rules;

[0091] S12: Input the BTOR2 model into the BTOR2AIGER converter, set the corresponding output parameters, and complete the conversion of the BTOR2 model into an AIGER model.

[0092] S2: Call the ABC - BMC, NuSMV or SimpleCAR model - checking tool to verify the AIGER model and obtain the verification result. Specifically including:

[0093] S21: Input the AIGER model into the model checking tool to determine whether the verification property is established and obtain the judgment result;

[0094] S22: If the judgment result is yes, the verification is successful and the output is safe; if the judgment result is no, the verification fails and a counterexample path from the initial state to the bad state is output.

[0095] Example 3

[0096] This embodiment uses a process in which one producer and three consumers mutually exclusively access a buffer to specifically illustrate an operating system concurrency control C code verification system based on model checking provided by the present invention.

[0097] First, the conversion from C code to BTOR2 code. The producer-consumer problem of concurrent control in an operating system is transformed into abstract C code. This C code can then be converted into a BTOR2 model using the predefined conversion table in this solution. The BTOR2 model first defines the necessary state variables, including a state representing the producer's program counter (PC) and three state variables corresponding to the PCs of the consumers. These state variables are used to track the execution status of the producer and consumer during buffer operations. Mutual exclusion semaphores, and the number of empty and occupied slots are also defined as state variables and initialized in the code to ensure that the initial state of the simulation environment is consistent with the C code. Next, conditional statements (such as ite and and) are used to implement the logical control of the producer and consumer, ensuring safe access to the buffer under mutually exclusive conditions. Finally, the production and consumption processes are simulated by updating the state variables. This conversion maintains the logical structure of the original C code, enabling it to be effectively expressed in BTOR2.

[0098] Second, to convert the BTOR2 model into the AIGER model, you can directly call the BTOR2AIGER conversion in Btor2Tools, which is provided in the developer's github repository. Using this tool, the developer only needs to specify the input BTOR2 file and set the corresponding output parameters to complete the conversion.

[0099] Third, model checking and counterexample output. Using a model checking tool to call the generated AIGER model automatically verifies whether the above code has any issues. If the locking is correct, the tool will output "safe," proving that the C code is safe. If there is a locking issue, the model will eventually reach a bad state, and a counterexample path from the initial state to the bad state will be output.

[0100] After the verification is completed, a .res file and a .log file will be generated according to the set output file location. The res file is used to record the verification counterexamples, and the log file is used to record the verification information, such as the total verification time, the number of times the SAT solver is called, etc.

[0101] If the verified property is established, that is, the verification is passed, the first line of the res file will be "0", such as Figure 2 If the verified property does not hold, that is, the verification fails, the first line of the res file will be "1", and the subsequent lines will give a counterexample, such as Figure 3 As shown, line 3 is the initial value of the latch variable, and lines 4-20 show the values of the input variables at each cycle. This counterexample represents the input to the model at different cycles. Based on these inputs, subsequent simulations can be used to calculate the values of each variable at different cycles, thereby deriving the complete process where the property is violated.

[0102] This invention provides a model-checking-based verification system and method for operating system concurrency control C code. Using a model conversion toolchain, C code is gradually converted into a BTOR2 model, and then into an AIGER model, to ensure compatibility with existing model checking tools. This replaces traditional theorem proving methods, reduces manual intervention, improves verification efficiency, and automatically generates counterexample paths to accurately locate system defects. This system fills a gap in the use of model checking methods for multi-core operating system code verification and expands the application of model checking technology in the software field.

[0103] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention rather than to limit the same. Although the present invention has been described in detail with reference to the preferred embodiments, those skilled in the art should understand that they can still modify or replace the technical solutions of the present invention with equivalents, and these modifications or equivalent replacements cannot cause the modified technical solutions to deviate from the spirit and scope of the technical solutions of the present invention.

Claims

1. A C code verification system for concurrent control of an operating system based on model checking, characterized in that: It includes a code conversion module and a verification module; The code conversion module converts the concurrent control C code of the target operating system into a BTOR2 model, and then converts the BTOR2 model into an AIGER model; The verification module is connected to the code conversion module and calls a model checking tool to verify the AIGER model.

2. The operating system concurrency control C code verification system based on model checking according to claim 1, characterized in that: The code conversion module includes a first conversion module and a second conversion module; The first conversion module converts the concurrent control C code of the target operating system into a BTOR2 model according to preset conversion rules; the conversion rules include: variable conversion rules, operator conversion rules, control structure conversion rules, and concurrent control conversion rules; The second conversion module is connected to the first conversion module and converts the BTOR2 model into an AIGER model; the BTOR2 model is input into a BTOR2AIGER converter, and corresponding output parameters are set to complete the conversion of the BTOR2 model into an AIGER model.

3. The operating system concurrency control C code verification system based on model checking according to claim 2, characterized in that: The first conversion module includes a variable conversion unit, an operator conversion unit, a control structure conversion unit, and a concurrent control conversion unit; The variable conversion unit converts the variables in the concurrent control C code of the target operating system into variables in the BTOR2 model; The operator conversion unit converts the operators in the concurrent control C code of the target operating system into operators in the BTOR2 model; The control structure conversion unit converts the control structures in the concurrent control C code of the target operating system into control structures in the BTOR2 model; The concurrent control conversion unit converts the concurrent control mechanism in the concurrent control C code of the target operating system into a control mechanism in the BTOR2 model.

4. The operating system concurrency control C code verification system based on model checking according to claim 3, characterized in that: The concurrent control mechanism specifically includes a semaphore mechanism and a mutex mechanism; The semaphore mechanism is used to manage access to shared resources, maps the operations of semaphores in C code to the logical constructs of BTOR2, and the value of the semaphore is represented as a bit vector in BTOR2; the wait operation of the semaphore is converted into a check and update of the current semaphore value. If the semaphore value is greater than 0, the semaphore value is decreased; otherwise, it enters the waiting state; The mutex mechanism involves the acquisition and release of locks in C language. The process of acquiring a lock in the BTOR2 model is represented by a conditional judgment. After successfully acquiring the lock, the state is updated. The state of the lock is modeled by a state variable, and effective state management is performed during resource access.

5. The operating system concurrency control C code verification system based on model checking according to claim 4, characterized in that: The verification module includes a call unit, a property verification unit, a counterexample search unit, and a result output unit; The call unit is connected to the code conversion module and calls the AIGER model; The property verification unit is connected to the call unit and determines whether the target operating system satisfies specific security properties under specific conditions according to the AIGER model; The property to be verified is P, and the B sequence is used to maintain the superset of the states of!P that reach the non-safe state. All states that reach!P in i steps will be in Bi. When there exists Bi that is a subset of the union of all Bj (j < i), the model is safe. The effectiveness of the security condition indicates that the B sequence will not expand further, and the union of B0 to Bi forms an invariant; The counterexample search unit is connected to the property verification unit and searches for counterexamples according to the output result of the property verification unit; The F sequence is a subset of states reached from the initial state I. If there is a state s in a state space Fi that is an unsafe state! P, then a path with I as the starting point and state s as the end point is obtained. This path is a counterexample to the property to be verified and will be returned; The result output unit is connected to the property verification unit and the counterexample search unit. After the verification is completed, a record verification counterexample file and a record verification information file are generated in the set output file location according to the results of the property verification unit and the counterexample search unit.

6. The operating system concurrency control C code verification system based on model checking according to claim 5, characterized in that: Model checking tools include ABC-BMC, NuSMV, or SimpleCAR; The model checking tool creates an abstract model M of a finite automaton for the operation of the system or model, creates a specification description φ in a formal language for the properties to be verified, and automatically runs to determine whether the model M satisfies M╞φ. If it does not satisfy the condition, a counterexample is automatically generated, generating a path from the initial state to the property violation state.

7. The operating system concurrency control C code verification system based on model checking according to claim 6, characterized in that: Convert the BTOR2 model to the AIGER model by performing the following steps: Call the BTOR2AIGER converter, input the BTOR2 model, generate a name from the AIG level serial number, assign a default name to the state without an explicitly associated name, set the corresponding output parameters, and complete the conversion of the BTOR2 model to the AIGER model.

8. A verification method for an operating system concurrent control C code verification system based on model checking according to any one of claims 1 to 7, characterized in that: Verification through operating system concurrency control C code includes the following steps: S1: Convert the target operating system concurrency control C code into an AIGER model; S2: Call ABC-BMC, NuSMV or SimpleCAR model checking tools to verify the AIGER model and obtain the verification results.

9. The method for verifying operating system concurrency control C code based on model checking according to claim 8, characterized in that: Step S1 specifically includes: S11: converting the target operating system concurrency control C code into a BTOR2 model according to preset conversion rules; the conversion rules include: variable conversion rules, operator conversion rules, control structure conversion rules and concurrency control conversion rules; S12: Input the BTOR2 model into the BTOR2AIGER converter, set corresponding output parameters, and complete the conversion of the BTOR2 model into the AIGER model.

10. The method for verifying C code of operating system concurrency control based on model checking according to claim 9, characterized in that: Step S2 specifically includes: S21: Input the AIGER model into the model checking tool to determine whether the verification property is established and obtain the judgment result; S22: If the judgment result is yes, the verification is successful and the output is safe; if the judgment result is no, the verification fails and a counterexample path from the initial state to the bad state is output.

Images