A verification system used in a runtime formal verification method for source code

Abstract

The present invention discloses a verification system applied to a runtime formal verification method for source code, the system comprising: a section class file and a monitor file automatic generation tool, a user can define an LTL linear temporal logic formula and a configuration file describing program properties, and the tool automatically generates a section class for monitoring program properties and a detector for monitoring program status; a modified SystemC simulation kernel is combined with a plug-in source code in the form of a section class and a detector to form an executable target file, and the file is run to detect the dynamic execution of the program and verify the properties of the system in real time. The present invention can be applied to the formal verification of embedded systems and large software systems, and can improve the security and reliability of software.

Description

Technical Field

[0001] The invention belongs to the field of formal verification, and in particular relates to a verification system applied to a runtime formal verification method for source code. Background Art

[0002] The security of embedded systems is very important. With the development of computer science, more and more embedded systems have penetrated into people's daily lives. People who travel need to take trains and planes, banks need to manage hundreds of millions of properties, and sick people need to go to the hospital for examination. All of these are inseparable from the support of embedded systems. Its security and reliability are related to people's information security, property security and even life safety. Therefore, how to ensure the security and reliability of embedded systems has become an important issue in its development. Testing is currently the most important method to ensure the safety and reliability of the system, but limited test cases cannot cover all situations of software operation. The introduction of formal methods has increased the reliability of embedded systems. There are two main methods of formal verification: theorem proof and model checking. Theorem proof is based on deductive reasoning and ensures the correctness of high-level specifications through a series of reasoning, but its proof process often requires manual intervention and has a low degree of automation, which is not suitable for large-scale applications. As the scale of the system increases, the number of states of the system model that needs to be verified also increases exponentially, resulting in state explosion, which is also a major problem in its application and practice. Summary of the invention

[0003] In order to overcome the above-mentioned defects of the prior art, the present invention proposes a lightweight formal verification method - runtime verification, whose verification process is based on the actual operation process of the monitored system. Once the behavior of the program violates certain properties, it can immediately give a reminder or respond. The runtime verification method of the present invention uses LTL linear temporal logic formulas to describe the verification properties and analyzes the program or the trajectory generated by the program. Compared with the test method, the runtime verification method of the present invention introduces a formal method, which is more flexible and scalable in the description of attributes and the monitoring of the program. The present invention introduces the runtime verification method into the SystemC program, which can improve its security and reliability.

[0004] The runtime formal verification method for source code proposed by the present invention comprises the following steps:

[0005] Step 1: Extract the security specifications that the source program needs to meet based on the source program's requirements, characterize the security specifications using LTL linear temporal logic, and specify the required parameters. The specific steps include:

[0006] Step A1: Based on the analysis of the source program requirement specifications, extract the security specifications that need to be met, use LTL linear temporal logic to describe the verification properties, and obtain its logical formula;

[0007] Step A2: Declare the class to be monitored in the source program, and define the corresponding data structure to point to the monitoring variables and extract the timing relationship of the variables.

[0008] Step 2: Write a configuration file based on the security specifications and specified parameters required by the program extracted in step 1, including the following steps:

[0009] Step B1: Specify the output path of the configuration file;

[0010] Step B2: Specify the configuration file name;

[0011] Step B3: Declare the monitored class in the source program;

[0012] Step B4: Declare a pointer to the monitored class, which can be used to point to the monitored member variable;

[0013] Step B5: Declare the monitored variable and specify the variable in the monitor to store the value of the monitored variable;

[0014] Step B6: Declare the type of the monitoring variable in the monitoring class;

[0015] Step B7: specifying a time period for the monitor to obtain the value of the monitoring variable;

[0016] Step B8: Write the LTL linear temporal logic formula of the safety specification in step 1 into the configuration file;

[0017] Step B9: Declare the header files that need to be included.

[0018] Step 3: Use the runtime verification tool to automatically generate the corresponding monitor file and aspect class file according to the configuration file, including the following steps:

[0019] Step C1: Use the tool written by the developers of this project to read the configuration file;

[0020] Step C2: converting the LTL linear temporal logic formula of the security specification in the configuration file into a monitor;

[0021] Step C3: Convert the variables to be monitored in the configuration file into a slice class.

[0022] Step 4: Use the tool to place the aspect class file into the source program to generate the source program after the instrumentation, including the following steps:

[0023] Step D1: Use the instrumentation tool to generate the puma.config file for compiler preprocessing to generate a knowledge base of code connection points;

[0024] Step D2: Move the generated aspect class file to the path where the source program is located. The instrumentation tool inserts the cross-cutting concern code into the source program according to the connection points in the knowledge base and the entry points in the aspect file.

[0025] Step 5: Modify the simulation kernel to make it suitable for runtime formal verification method (this step only needs to be performed once in the entire method) including the following steps:

[0026] Step E1: modify the context scheduling function in the kernel;

[0027] Step E2: Modify the state transition function in the kernel.

[0028] Step 6: Compile the source program and monitor file after the stub and execute them to obtain the running trajectory. Use the monitor to verify the obtained running trajectory, including the following steps:

[0029] Step F1: Run the source program after the stub is inserted to obtain the running track up to the current moment;

[0030] Step F2: The running trajectory is transmitted to the monitor, and the running trajectory is monitored by the monitor to verify the properties.

[0031] Step 7: Determine whether the source program after the plugging meets the properties based on the verification results. If it does not meet the properties, record the corresponding running track or perform automatic program repair; if it meets the properties, continue to monitor the program running, including the following steps:

[0032] Step G1: If the verification is correct, continue to monitor the running of the source program;

[0033] Step G2: If the running trajectory does not meet the properties, record the running trajectory or use the program self-repair function and continue running.

[0034] In the runtime formal verification method for source code proposed by the present invention, the source code can be not only SystemC source code, but also C source code and C++ source code.

[0035] The present invention proposes a runtime formal verification system for source code, which includes: an automatic generation tool for aspect class files and monitor files. Users can define LTL linear temporal logic formulas and configuration files that describe system properties, and the tool automatically generates aspect classes for monitoring program properties and detectors for monitoring program status. The modified SystemC simulation kernel is jointly compiled with the plugged source code in the form of aspect classes and the detector to form an executable target file, which is run to detect the dynamic execution of the program and verify the system properties in real time.

[0036] The present invention is a runtime formal verification method for source code. According to the properties (safety specifications) that the SystemC source program needs to meet, corresponding aspect class files and monitoring class files are generated, and the aspect class files are placed into the source program using a tool, thereby achieving the purpose of real-time monitoring of program properties in the actual program running environment.

[0037] In the method of the present invention, how to extract the correct security specification is the most important link in runtime verification, which is related to the validity of the verification result. Therefore, in step 1, the security specification to be met must be extracted from the system requirements, and the security specification is formally described using the LTL linear temporal logic formula, and a monitor of corresponding properties is generated based on the LTL formula. By using the runtime verification method of the present invention, the source program is dynamically analyzed in real time to timely discover program errors and defects, thereby ensuring the safety and reliability of the program.

[0038] The method of the present invention can be applied to the formal verification of embedded systems to improve the security and reliability of the system. Currently, there is no research on the runtime verification of SystemC programs. Compared with traditional formal verification methods such as model checking and theorem proving, the runtime verification technology is dynamic verification in nature and belongs to lightweight formal verification. Therefore, the runtime verification technology provided by the present invention is a supplement to ensure the security and reliability of the system and has high practicality. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] Figure 1 It is a flow chart of the runtime verification method for SystemC program of the present invention.

[0040] Figure 2 The diagram is a design diagram of a self-runtime verification system in a runtime verification method for SystemC programs.

[0041] Figure 3 The flowchart of the runtime verification method for SystemC program of the present invention is shown in FIG. DETAILED DESCRIPTION

[0042] The present invention is further described in detail with reference to the following specific examples and drawings. The process, conditions, experimental methods, etc. for implementing the present invention, except for the contents specifically mentioned below, are all common knowledge and common common sense in the art and are not particularly limited by the present invention.

[0043] The runtime formal verification method of the source code of the present invention mainly analyzes the system requirement specifications, extracts the security properties that need to be satisfied by the written source program, and writes the corresponding configuration file. According to the parameters such as the aspect class and the monitor output path, monitoring variables, value acquisition stage, property expression, and required header files specified in the configuration file, the aspect class and the monitor are automatically generated using a generation tool. The aspect class is placed into the source program using a plug-in tool, and this process is also called plug-in. The source program after the plug-in is completed is compiled to generate an executable file, and the source program is run. During the running of the source program, the monitor will monitor the verification properties according to the running trajectory of the program. If an event that violates the properties occurs during the running process, the monitor will record the running trajectory to correct the source program. If the verification properties are always satisfied during the running process, the monitoring will continue during the continued running process.

[0044] like Figure 1 The flowchart of the runtime formal verification method for SystemC program according to the embodiment of the present invention is shown, comprising the following steps:

[0045] Step 1: Analyze the security specifications that the SystemC source program needs to meet according to the system requirements, and use LTL linear temporal logic formulas to describe the security specifications. Since the system is developed according to the requirements specifications, but the requirements specifications cannot guarantee that the developed software system is safe and reliable, it is necessary to extract the security specifications that guarantee the safety and reliability of the system based on the requirements specifications. How to extract the correct security specifications is the most important part of runtime verification and is related to the validity of the verification results. Therefore, in step 1, we must first extract the security specifications to be met from the system requirements, and use LTL linear temporal logic formulas to formally describe the security specifications. Based on the LTL formulas, corresponding property monitors will be generated.

[0046] During the development of SystemC systems, the safety specifications that need to be extracted mainly focus on system functional safety, memory management, address access out-of-bounds, and safe use of pointers. For example, in a classic producer-consumer program, it is necessary to ensure that the consumer can correctly and completely read the string generated by the producer every time. Therefore, it is necessary to extract the properties that describe the correct string reading process and correctly characterize the properties through LTL linear temporal logic formulas to ensure the correctness of the program.

[0047] Step 2: Write the corresponding configuration file. The configuration file contains the output path of the monitor file, the monitor file name, the execution trace output option, the declaration of the class to be monitored, the definition of the data type and the variable value acquisition time point, and the LTL linear temporal logic expression of the safety specification. Table 1 shows the parameters required for the configuration file.

[0048] Table 1 Configuration file required parameters

[0049]

[0050]

[0051] Not all parameters in Table 1 need to be specified. When verifying different programs, different parameters can be selected according to the different security specifications that the programs need to meet, so as to achieve the purpose of a suitable verification method.

[0052] Step 3: Use the aspect class and monitor generation tool to generate the corresponding aspect class file and the monitor file for verifying the property according to the configuration file written in step 2. The tool automatically generates aspect class files and monitor files. The monitor construction method based on finite state automata is adopted. First, the property specification to be verified is expressed as an LTL paradigm, and the LTL paradigm is converted into a corresponding finite state automata. The monitor file is the specific implementation of the automata.

[0053] Aspect classes are program components based on aspect-oriented programming. Aspect-oriented programming programs consist of two parts: the basic code is used to implement the core concerns of the system, that is, the source program developed according to the requirements specification, and the other part is the aspect code, which is used to implement cross-cutting concerns. After being compiled by the corresponding aspect language compiler, the target program code that combines the core concerns and cross-cutting concerns is output. Aspect classes contain notifications, that is, the target execution actions of cross-cutting concerns. There are usually three types of associations between notifications and pointcuts. The first is to execute the notification action before entering the pointcut, the second is to skip the original pointcut and execute the notification action, and the third is to execute the notification action after leaving the pointcut. Pointcuts and notifications together constitute a module of a concern, and a collection of several concerns constitutes an aspect. Aspects usually have a structure similar to a class. Pointcuts are similar to variable declarations in object-oriented programming, and notifications are similar to method declarations in object-oriented programming.

[0054] Step 4: Use tools to insert the source program according to the aspect class file and monitor file generated in step 3. Before inserting, you must first match the entry points in the source program. The entry point is an abstract description of a type of access point that meets specific conditions. The entry point includes a specific location in the static structure of the code or a specific moment in the program execution process. For aspect-oriented programming (AOP), it is necessary to execute specific notification target code at a specific entry point, so the entry point in the aspect code and the access point in the program must be matched. The tool first uses the compiler to compile the source file to generate an abstract syntax tree. Based on the abstract syntax tree, it finds all possible access points according to the supported entry point types and all possible entry point types. It records the access point type, name, parameters, file location and other related information in the knowledge base. In this way, in the subsequent matching process, the entry point and the knowledge base can be directly matched. This matching method avoids repeated compilation caused by multiple matching of the same file through the knowledge base, improves reusability, and then matches the connection points in the knowledge base with the entry points in the aspect file, inserting the corresponding cross-cutting concern code at the matching code location. After completing the insertion of each file of the source program, the entire insertion process ends, and the source program after the insertion is obtained.

[0055] Step 5: Modify the SystemC simulation kernel to make it suitable for runtime verification. This process only needs to be done once for runtime verification based on SystemC. To realize runtime monitoring of the program, the monitor needs to monitor the SystemC kernel state in real time. To realize kernel state monitoring, one method is to implement an API that returns relevant data of the currently executed kernel, and another way is to modify the kernel to send relevant information. In this embodiment, the second method is selected. When the function is called, the kernel sends status update information, and the monitor is triggered and performs monitoring after reaching the relevant sampling point. In order to add as little code as possible, a new object Observer with corresponding functions is encapsulated in the kernel code. Observer stores a reference to the monitor, receives updates to the kernel state, and then notifies the monitor that needs to be executed at the current sampling point.

[0056] Step 6: Install the SystemC class library and simulation kernel, and use the compiler to compile the SystemC program after the stub to generate executable code. SystemC is a programming language based on C++. It adds some important concepts on the basis of C++, such as concurrency (multiple processors execute simultaneously), timed events, and data types. SystemC also adds a class library composed of functions, data types, and other language structure functions written in legal C++ code. This class library provides a powerful new mechanism for modeling system structures with hardware timing, concurrency, and response behaviors. In addition to adding the SystemC class library, you also need to install the simulation kernel. Based on the simulation kernel, you can write SystemC code to describe the design or system specifications and simulate them. Because SystemC is C++, you can use the standard C++ programming language and development tools to simulate, debug, and study it.

[0057] Step 7: The monitor verifies whether the source program meets the required safety specifications based on the running trajectory of the SystemC model. The safety specifications are described by LTL formulas. Any LTL formula has a language-equivalent finite state automaton, which means that the problem of verifying whether the running trajectory satisfies the LTL formula can be transformed into the problem of whether the sequence is accepted by the corresponding finite state automaton. Therefore, the program running trajectory is verified based on the monitor file generated in step 3. The monitor is a specific implementation of the finite state automaton. The alphabet of the automaton is the basic events of the program running. The running trajectory of the program composed of basic events is used as the input of the monitor. When the running trajectory can always be accepted by the corresponding automaton, it is proved that the program meets the property. If the trajectory is not accepted, it proves that the program running trajectory does not meet the safety specifications. The path that does not meet the safety specifications is recorded according to the recording parameters in the configuration file.

[0058] Example 1

[0059] This specific embodiment takes the producer-consumer program as an example, and performs runtime verification on the security specifications that it needs to meet. For the producer-consumer program, the producer stores data in the buffer, and the consumer reads data from the buffer. The consumer must ensure the integrity of the data during the reading process. In this embodiment, the producer stores a string in the buffer, and the consumer reads the string. The security specification that needs to be met is that the string read by the consumer is complete, that is, the program cannot read only part of the string during operation.

[0060] In this specific embodiment, the SystemC program runtime verification method of the present invention is used to verify the security specifications that the producer and consumer programs need to meet, and the specific steps are as follows:

[0061] Step 1: Analyze the security specifications that producer and consumer programs need to meet. Based on the functional requirements of producers and consumers, the following security specifications are summarized: Consumers must read complete strings without missing characters or reading errors.

[0062] In the security specification, LTL linear temporal logic formula is used to characterize the security specification. For the security specification of consumers reading strings, we must first identify the first character of the string, and based on the length and content of the string, limit the reading of the last character of the string to a certain time, so as to ensure the integrity of the read string.

[0063] Step 2: Write the configuration file.

[0064] Step 1: Specify the output path of the monitor file;

[0065] Step 2: Specify the monitor file name;

[0066] Step 3: Declare the monitored classes in the source program, which are the producer class and the consumer class respectively;

[0067] Step 4: Declare a pointer to the monitored class, which can be used to point to the monitored member variables in the producer class and the consumer class;

[0068] Step 5: Declare the monitored variable and specify the variable in the monitor to store the value of the monitored variable;

[0069] Step 6: Declare the type of the monitoring variable in the monitoring class;

[0070] Step 7: Specify the time period for the monitor to obtain the monitored variable value;

[0071] Step 8: Write the LTL linear logic expression of the safety specification in step 1 into the configuration file;

[0072] Step 9: Declare the header files that need to be included, in this example, the header files of the producer class and the consumer class;

[0073] The configuration files will vary according to different policy parameters, and users can choose different verification policies according to their needs.

[0074] Step 3: Use the aspect class and monitor generation tool to automatically generate aspect classes and monitors based on the configuration file. The command format is as follows: tim-conf path, where path is the configuration file path.

[0075] Step 4: Use the AC++ tool to insert stubs into the producer and consumer source programs. Use the AC++ tool command to insert stubs into each file of the source program. The command format is as follows:

[0076] ac++ -c SOURCE_HOME / file name

[0077] -o TARGET_HOME / file name

[0078] -p SOURCE_HOME / -I SOURCE_HOME

[0079] -I SYSTEMC_HOME / include

[0080] --config ASPECTC_HOME / puma.config

[0081] The SOURCE_HOME parameter is the source file path, the TARGET_HOME parameter is the output path of the program after instrumentation, the SYSTEMC_HOME parameter is the SystemC class library installation path, and the ASPECTC_HOME parameter is the aspect class file path.

[0082] Step 5: Modify the SystemC simulation kernel. First, create a new mon_observer class, define related member variables and member functions, declare the mon_observer class in the sc_simcontext.h header file, and declare it as a friend class of the sc_simcontext class. Declare a pointer observer pointing to the mon_observer class. In the sc_simcontext.cpp file, use the pointer observer to call the corresponding function at the kernel state change point.

[0083] Step 6: Install the SystemC class library and simulation kernel, use gcc to compile the producer and consumer source code, and generate executable files.

[0084] Step 7: Run the executable file and use the monitor to monitor the program running status, and finally verify that the consumer program reads the string correctly.

[0085] Example 2

[0086] This specific embodiment takes the ALU arithmetic logic unit program as an example to perform runtime verification on the safety specifications it needs to meet. The arithmetic logic unit program calculates and outputs the result based on the specified operands and operation codes. If the divisor is zero in the division operation, it is necessary to promptly detect the error in the operation. In this embodiment, the monitor needs to monitor the divisor value in the division operation. If the divisor is zero, an error must be reported in time to prevent serious consequences.

[0087] In this specific embodiment, the SystemC program runtime verification method of the present invention is used to verify the safety specifications that the ALU arithmetic logic unit program needs to meet, and the specific steps are as follows:

[0088] Step 1: Analyze the safety specifications that the ALU program needs to meet. Based on the calculation requirements, the following safety specifications are summarized: When the ALU performs a division operation, it needs to report errors in a timely manner, and no false alarms or missed alarms should occur.

[0089] In the safety specification, LTL linear temporal logic formulas are used to characterize the safety specification. For the safety specification of the division operation, we must first clarify the variable that stores the divisor in the division operation. According to the content of the variable, when the value is zero, check whether the value of the program status register is set to the zero status code, so as to ensure the correctness of the calculation process.

[0090] Step 2: Write the configuration file.

[0091] Step 1: Specify the output path of the monitor file;

[0092] Step 2: Specify the monitor file name;

[0093] Step 3: Declare the monitored classes in the source program, which are the arithmetic logic unit classes in this case;

[0094] Step 4: Declare a pointer to the monitored class, which can be used to point to the monitored operand variable;

[0095] Step 5: Declare the monitored variable and specify the variable in the monitor to store the value of the monitored variable;

[0096] Step 6: Declare the type of the monitoring variable in the monitoring class;

[0097] Step 7: Specify the time period for the monitor to obtain the monitored variable value;

[0098] Step 8: Write the LTL linear logic expression of the safety specification in step 1 into the configuration file;

[0099] Step 9: Declare the header files that need to be included. In this example, it is the header file that defines the assembly system instructions.

[0100] The configuration files will vary according to different policy parameters, and users can choose different verification policies according to their needs.

[0101] Step 3: Use the aspect class and monitor generation tool to automatically generate aspect classes and monitors based on the configuration file. The command format is as follows: tim-conf path, where path is the configuration file path.

[0102] Step 4: Use the AC++ tool to insert stubs into the producer and consumer source programs. Use the AC++ tool command to insert stubs into each file of the source program. The command format is as follows:

[0103] ac++ -c SOURCE_HOME / file name

[0104] -o TARGET_HOME / file name

[0105] -p SOURCE_HOME / -I SOURCE_HOME

[0106] -I SYSTEMC_HOME / include

[0107] --config ASPECTC_HOME / puma.config

[0108] The SOURCE_HOME parameter is the source file path, the TARGET_HOME parameter is the output path of the program after instrumentation, the SYSTEMC_HOME parameter is the SystemC class library installation path, and the ASPECTC_HOME parameter is the aspect class file path.

[0109] Step 5: Modify the SystemC simulation kernel. First, create a new mon_observer class, define related member variables and member functions, declare the mon_observer class in the sc_simcontext.h header file, and declare it as a friend class of the sc_simcontext class. Declare a pointer observer pointing to the mon_observer class. In the sc_simcontext.cpp file, use the pointer observer to call the corresponding function at the kernel state change point.

[0110] Step 6: Install the SystemC class library and simulation kernel, use gcc to compile the arithmetic logic unit source program, and generate an executable file.

[0111] Step 7: Run the executable file, use the monitor to monitor the program running, and finally verify that the program correctly handles the situation where the divisor is zero.

[0112] Figure 2 In order to verify the system design diagram during self-runtime in the runtime verification method of SystemC program, during the running process of SystemC source program after stubbing, when the monitored variable changes, an event will be generated, and the event will be received by the event receiver of the monitor. The monitor uses the property verifier to verify the received event to determine whether the event violates the property. If the event violates the property (safety specification), corresponding feedback will be generated, such as reporting a program error.

[0113] Figure 3 This is a workflow diagram of the runtime verification method for SystemC programs of the present invention. First, the user uses linear temporal logic (LTL) expressions to describe the security specifications that the system needs to meet, and at the same time defines the aspect class and the parameters required by the file and monitor file automatic generation tool to write a configuration file. Next, the aspect class for detecting program properties and the monitor for monitoring the program running status are generated through the configuration file and the LTL linear logic expression. Next, the aspect class is woven into the source program through the AC++ tool to generate the source program after stubbing. Finally, the runtime verification of the program is realized by running the source program after stubbing on the SystemC simulation kernel.

[0114] The protection content of the present invention is not limited to the above embodiments. Without departing from the spirit and scope of the inventive concept, changes and advantages that can be thought of by those skilled in the art are included in the present invention and are protected by the attached claims.

Claims

1. A verification system applied to a runtime formal verification method for source code, characterized in that: The runtime formal verification method for source code comprises the following steps: Step 1: Extract the security specifications that the source program needs to meet based on the source program's requirement specifications, characterize the security specifications using LTL linear temporal logic, and specify the required parameters; Step 2: Write a configuration file based on the extracted security specifications and specified required parameters; Step 3: Use the runtime verification tool to automatically generate corresponding monitor files and aspect class files according to the configuration file; Step 4: Use a tool to place the section class file into the source program to generate the source program after the plug-in; the step 4 includes the following steps: Step D1: Use the instrumentation tool to generate the puma.config file for compiler preprocessing to generate a knowledge base of code connection points; Step D2: Move the generated aspect class file to the path where the source program is located, and the instrumentation tool inserts the cross-cutting concern code into the source program according to the connection points in the knowledge base and the entry points in the aspect file; Step 5: Modify the simulation kernel to make it suitable for runtime formal verification method; Step 5 includes the following steps: Step E1: modify the context scheduling function in the kernel; Step E2: Modify the state transition function in the kernel; Step 6: Compile the source program and monitor file after the stub and execute them to obtain the running trajectory, and use the monitor to verify the obtained running trajectory; Step 7: Determine whether the source program after the stub meets the properties according to the verification results; if not, record the corresponding running track or perform automatic program repair; if it meets the properties, continue to monitor the program running; The system includes: an automatic generation tool for aspect class files and monitor files, through which users can define LTL linear temporal logic formulas and configuration files that describe program properties, and automatically generate aspect classes for monitoring program properties and detectors for monitoring program status through the tool; by jointly compiling the modified simulation kernel with the plugged source code in the form of aspect classes and the detector, an executable target file is formed, and the file is run to detect the dynamic execution of the program and verify the properties of the system in real time.

2. The verification system applied to the runtime formal verification method for source code according to claim 1, characterized in that: The step 1 comprises the following steps: Step A1: Based on the analysis of the source program requirement specifications, extract the security specifications that need to be met, use LTL linear temporal logic to describe the verification properties, and obtain its logical formula; Step A2: Declare the class to be monitored in the source program, and define the corresponding data structure to point to the monitoring variables and extract the timing relationship of the variables.

3. The verification system applied to the runtime formal verification method for source code according to claim 2, characterized in that: In the step 1, the LTL linear temporal logic formula is used to represent the temporal relationship between variables in the source program.

4. The verification system applied to the runtime formal verification method for source code according to claim 1, characterized in that: In the step 2, the step of writing the configuration file specifically includes: Step B1: Specify the output path of the configuration file; Step B2: Specify the configuration file name; Step B3: Declare the monitored class in the source program; Step B4: Declare a pointer to the monitored class, which can be used to point to the monitored member variable; Step B5: Declare the monitored variable and specify the variable in the monitor to store the value of the monitored variable; Step B6: Declare the type of the monitoring variable in the monitoring class; Step B7: specifying a time period for the monitor to obtain the value of the monitoring variable; Step B8: writing the LTL linear temporal logic formula of the safety specification in step 1 into the configuration file; Step B9: Declare the header files that need to be included.

5. The verification system applied to the runtime formal verification method for source code according to claim 1, characterized in that: The step three comprises the following steps: Step C1: Use the tool written by the developers of this project to read the configuration file; Step C2: converting the LTL linear temporal logic formula of the security specification in the configuration file into a monitor; Step C3: Convert the variables to be monitored in the configuration file into a slice class.

6. The verification system applied to the runtime formal verification method for source code according to claim 1, characterized in that: The step six comprises the following steps: Step F1: Run the source program after the stub is inserted to obtain the running track up to the current moment; Step F2: The running trajectory is transmitted to the monitor, and the running trajectory is monitored by the monitor to verify the properties.

7. The verification system applied to the runtime formal verification method for source code according to claim 1, characterized in that: The step seven comprises the following steps: Step G1: If the verification is correct, continue to monitor the running of the source program; Step G2: If the running trajectory does not meet the properties, the running trajectory is recorded or the program self-repair function is used before continuing to run.

8. The verification system applied to the runtime formal verification method for source code according to claim 1, characterized in that: The source program is a SystemC source code, a C source code or a C++ source code.

Images