CN108536581B - 一种针对源代码的运行时形式化验证方法 - Google Patents

Abstract

本发明公开了一种针对源代码的运行时形式化验证方法，根据源程序所需满足的性质以及工具所需参数编写用于生成监视器与切面类的配置文件；根据编写的配置文件使用运行时验证工具自动化生成监视器以及切面类；根据生成的切面类将所涉及的变量置入源程序；修改仿真内核以适用于运行时验证方法；使用生成的监测器对插桩后的源程序运行状态进行实时监测；监测器根据程序运行的轨迹对性质进行形式化验证，若出现违反验性质的路径，则记录或者进行程序的自动修复。本发明所述方法可以应用到嵌入式系统及大型软件系统的形式化验证中，能够提高软件的安全性、可靠性。

Description

一种针对源代码的运行时形式化验证方法

技术领域

本发明属于形式化验证领域，具体涉及一种针对源代码的的运行时验证方法。

背景技术

软件系统的安全性是非常重要的，随着计算机科学的发展，越来越多的软件系统渗透到人们的日常生活之中，出行的人们需要乘坐列车、飞机，银行需要对数以亿计的财产进行管理，生病的人需要到医院进行检查，这些都离不开软件的支持，软件系统关系着人民的信息安全、财产安全乃至生命安全。因此如何保证软件系统的安全性，成为软件开发的重要问题。目前主要的验证方法有三种：定理证明、模型检测以及软件测试。定理证明是以演绎推理为基础，试图证明通过一定的软件开发步骤和阶段最终保证高层规约的实现，但其证明过程经常需要人工干预，自动化程度比较低，不适合大规模应用。模型检测是以系统模型为基础致力于检查系统执行是否都满足给定的性质，自动化程度高，但是模型检测针对的是真实系统的抽象模型，而不是真实的系统，并且存在状态爆炸问题。而软件测试可以用来发现软件的漏洞，但有限的测试用例无法覆盖软件运行的所有情形。

发明内容

为了克服现有技术的上述缺陷，本发明提出了一种针对轻量级形式化验证方法——运行时验证，其验证过程基于被监控软件的实际运行过程，一旦程序的行为违反某些性质，能够立即给予提醒或作出反应。本发明运行时验证方法使用LTL线性逻辑表达式对验证性质进行描述，针对程序或者程序产生的轨迹进行分析，其复杂度比模型检测、定理证明方法要低；与测试方法相比，本发明运行时验证方法引入了形式化方法，对属性的描述以及对程序的监控方面更具灵活性和可扩展性。本发明将运行时验证方法引入到SystemC程序中，可提高其安全性和正确性。

本发明提出的针对源代码的运行时形式化验证方法，包括以下步骤：

步骤一：根据SystemC源程序的需求规范，提取SystemC源程序所需满足的安全规范，使用LTL线性逻辑表达式对安全规范进行刻画（形式化的描述），并指定工具所需参数；

其中，工具参数包括文件输入输出路径及格式、插入点定义和模块性质、变量值获取时间点、时间触发条件以及定义数据类型等；

其中，所述LTL线性逻辑表达式是指描述SystemC源程序所需满足的安全规范的形式化表达式，用于验证字符串读取正确性；所述LTL线性逻辑表达式为G <= #2000 ((c_read = 38) => (F <= #14 (c_read = 64)))。

步骤二：根据步骤一中提取的所述程序所需满足的安全规范以及指定的工具所需参数编写配置文件；

其中，所述配置文件中包含监视器文件的输出路径、监视器文件名、执行轨迹输出选项、声明需监视的类、定义数据类型及变量值获取时间点以及安全规范的LTL线性时态逻辑表达式。

其中，所述编写配置文件的步骤包括：

第一步：指定监视器文件的输出路径；

第二步：指定监视器文件名称；

第三步：声明源程序中被监视类，在这里分别是生产者Producer类与消费者Consumer类；

第四步：声明指向被监视类的指针，使用该指针可以指向生产者类与消费者类中被监视的成员变量；

第五步：声明被监视变量，并指定监视器中的变量来存储被监视变量的值；

第六步：声明监视类中监视变量的类型；

第七步：指定监视器获取监视变量值的时间段；

第八步：将步骤一中安全规范的LTL线性逻辑表达式写入配置文件；

第九步：声明需要包含的头文件，在本实例中为生产者类与消费者类的头文件。

本发明配置文件所需的参数如表1所示，配置文件根据不同策略参数会有所不同，用户可根据需求选择不同验证策略。

步骤三：根据所述配置文件使用运行时验证工具（切面类文件及监视器文件生成工具）自动生成相应的监视器文件以及切面类文件；

其中，所述监视器文件为验证性质的文件。

其中，所述运行时验证工具为TIM。

其中，在配置文件中明确切面类文件与监视器文件的输出路径、监测变量、取值阶段、性质表达式、所需头文件等参数。

步骤四：使用AC++工具将切面类文件织入源程序，生成插桩后的源程序；

步骤五：修改SystemC仿真内核，使其适用于运行时验证方法；

步骤六：编译插桩后的源程序并执行，根据插桩后的源程序的运行轨迹，使用监视器文件对插桩后的源程序进行性质验证；

步骤七：判断插桩后的源程序是否满足验证性质，若不满足性质，对相应的运行轨迹进行记录或者进行良好的干预和调控系统行为；若满足性质，则不做任何处理。

其中，所述验证性质是指程序所需满足的安全规范以及功能。

本发明提出的针对源代码的运行时形式化验证方法中，所述步骤一具体包括以下步骤：

步骤A1：根据对源程序需求规范的分析，提取所需满足的安全规范，使用LTL线性逻辑表达式来描述验证性质；

步骤A2：指定监视器文件输出路径和名称；

步骤A3：声明源程序中要监测的类，并定义相应的数据结构指向监测变量以及提取变量的时间点。

本发明提出的针对源代码的运行时形式化验证方法中，所述步骤四具体包括以下步骤：

步骤B1：使用AspectC++工具生成puma.config文件，用于编译器进行预处理，生成代码连接点的知识库；

步骤B2：将生成的切面类文件移动到源程序所在的路径下，AspectC++工具根据知识库中的连接点和切面文件中的切入点将横切关注点代码插入源程序。

本发明提出的针对源代码的运行时形式化验证方法中，所述步骤六中根据插桩后的源程序的运行轨迹，使用监视器文件对插桩后的源程序进行监测（进行性质验证），具体包括以下步骤：

步骤C1：根据LTL线性逻辑表达式生成的有限状态自动机进行性质验证，自动机开始设置为指定的初始状态，当接收到运行轨迹中的变量值后，自动机根据接收到的变量值进行状态转移；

其中，所述LTL线性逻辑表达式为描述SystemC源源代码的所需满足的安全规范的形式化表达式，用于验证字符串读取正确性；所述LTL线性逻辑表达式为G <= #2000 ((c_read = 38) => (F <= #14 (c_read = 64)))。

步骤C2：当插桩后的源程序的运行轨迹中出现某一变量值造成自动机转移到不可接收状态时，则插桩后的源程序的运行违反了验证性质，此时需记录该轨迹，并需对该运行轨迹进行记录或者进行良好的干预和调控系统行为；所述良好的干预是指及时报告错误；所述调控系统行为是指修正程序的运行错误。

本发明提出的针对源代码的运行时形式化验证方法中，所述程序包括SystemC、C、C++。

本发明还提供了一种用于针对源代码的运行时形式化验证系统，该系统包括：切面类文件及监视器文件自动生成工具，用户可定义描述程序性质的LTL线性逻辑表达式以及配置文件，通过该工具自动生成监测程序性质的切面类以及监测程序状态的检测器。

本发明针对源代码的运行时形式化验证方法，根据SystemC源程序所需满足的性质（安全规范），生成相应的切面类文件及监视器文件，使用AspectC++工具将切面类文件织入源程序，实现了在程序真实运行环境下对程序性质进行实时监测的目的。本发明所述方法在，如何提取正确的安全规范是运行时验证中最重要的环节，关系到验证结果的有效性，因此在步骤一中首先要从软件的需求中提取所要满足的安全规范，并使用LTL线性逻辑表达式对安全规范进行形式化的描述，基于LTL表达式会产生相应性质的监视器。通过运用本发明运行时验证方法，可以对源程序进行实时的动态分析，以及时发现程序的错误和缺陷，保证程序的安全性和可靠性。本发明所述方法可以应用到嵌入式系统及大型软件系统的形式化验证中，能够提高软件的安全性、可靠性。当前并没有对SystemC程序的运行时验证方面的研究，与传统的形式化验证方法如模型检测、定理证明相比，运行时验证技术在实际软件系统中进行性质验证，避免了传统形式化验证方法中需要对系统刻画的繁重步骤，并且结合传统形式化验证技术的优点使用时态逻辑描述性质规约，具有形式化验证的验证能力。同时运行时验证技术可以实时的发现系统中的缺陷，并且可以尽早的避免缺陷造成严重后果，因此本发明提供的运行时验证技术作为传统验证技术的一种补充，具有很高的实用性。

附图说明

图1表示本发明针对SystemC程序的运行时验证方法的流程示意图。

图2表示针对SystemC程序的运行时验证方法中自运行时验证系统设计图。

图3表示本发明针对SystemC程序的运行时验证方法的工作流程图。

具体实施方式

结合以下具体实施例和附图，对本发明作进一步的详细说明。实施本发明的过程、条件、实验方法等，除以下专门提及的内容之外，均为本领域的普遍知识和公知常识，本发明没有特别限制内容。

本发明针对源代码的的运行时形式化验证方法主要通过分析SystemC源程序，提取SystemC源程序所需满足的安全性质编写配置文件，根据配置文件使用切面类及监视器生成工具自动化生成切面类及监视器，在配置文件中明确切面类与监视器输出路径、监测变量、取值阶段、性质表达式、所需头文件等参数。在切面类及监视器生成工具根据配置文件参数以及性质描述生成相应切面类和监视器后，使用AspectC++工具将切面类织入SystemC源程序，该过程也称为插桩。将插桩完成后的源程序进行编译生成可执行文件，运行源程序。在源程序运行过程中，监视器会根据程序的运行轨迹对验证性质进行监测，若运行过程中发生违反性质的事件，监视器会记录下该运行轨迹，用来对源程序进行修正，若运行过程中验证性质一直满足直到外界停止源程序的运行，则证明源程序直到截止时间为止满足安全性质。

如图1所示，是本发明的针对SystemC程序的运行时形式化验证方法的流程图，包括以下步骤：

步骤一：根据系统需求分析SystemC源程序所需满足的安全规范，使用LTL线性逻辑表达式描述安全规范。由于软件系统是根据需求规范开发的，但是需求规范并不能保证开发的软件系统是安全可靠的，所以必须要在需求规范的基础之上提取出保证软件系统安全可靠性的安全规范，以保证系统的安全可靠。而如何提取正确的安全规范是运行时验证中最重要的环节，关系到验证结果的有效性。因此在步骤一中首先要从软件的需求中提取所要满足的安全规范，并使用LTL线性逻辑表达式对安全规范进行形式化的描述，基于LTL表达式会产生相应的性质监视器。

在SystemC系统的开发过程中，需要提取的安全规范主要集中在系统功能是否正确实现、内存管理、地址访问越界以及指针使用等方面。例如：在经典的生产者消费者程序中，需要保证消费者每次能够正确完整的读取生产者所产生的字符串。因此需要提取描述正确读取字符串过程的性质，通过LTL线性逻辑表达式正确刻画性质，以保证程序的正确性。

步骤二：编写相应的配置文件。配置文件中包含监视器文件的输出路径、监视器文件名、执行轨迹输出选项、声明需监视的类、定义数据类型及变量值获取时间点以及安全规范的LTL线性时态逻辑表达式。如表1所示，配置文件所需的参数。

表1 配置文件所需参数

- outputfile	定义监视器文件输出路径
		- output_file	定义监视器头文件输出路径
- mon_name	定义监视器文件名称
		- write_to_file	定义是否记录运行轨迹
- include	定义包含的头文件
		- usertype	定义需要监测的类名称
- type	定义指向监测类的指针
		- attribute	定义指针指向的变量及监视器相应变量
- att_type	定义监视器相应变量数据类型
		- location	定义监视函数
- formula	定义安全规范的LTL表达式
		- time_resolution	定义变量值获取时间点
- comment	定义注释语句，以’#’开头

表1中的参数并不是所有都要指定，在验证不同程序时可以根据程序所需满足的不同安全规范选择不同的参数指定，以达到合适验证方式的目的。

步骤三：根据步骤二编写的配置文件使用切面类及监视器生成工具TIM生成相应切面类文件和验证性质的监视器文件。因此工具自动化生成切面类文件及监视器文件实现过程采用了模型检测领域中熟知的基于有限状态自动机的监控器构造方法，首先将被验证的性质规约表示成LTL合式公式，将该LTL合式公式转换为一个对应的有限状态自动机，监视器文件为该自动机的具体实现。

切面类是基于面向切面编程中的程序组成元素，面向切面编程中的程序包含两个部分，基础代码用于实现系统的核心关注点，即根据需求规范所开发的源程序，另一部分为切面代码，用于实现横切关注点，经过相应的切面语言的编译器编译之后，输出组合了核心关注点和横切关注点的目标程序代码。切面类中包含通知，即横切关注点的目标执行动作，通知和切入点之间通常有三种关联关系，第一种是在进入切入点之前执行通知动作，第二种是跳过原切入点执行通知动作，第三种是在离开切入点之后执行通知动作。切入点和通知共同构成了一个关注点的模块，若干个关注点的集合则构成了一个切面。切面通常有和类相似的结构，切入点类似于面向对象中的变量声明，通知类似于面向对象中的方法声明。

步骤四：根据步骤三生成的切面类文件及监视器文件使用AspectC++工具对源程序进行插桩。在插桩之前首先要对在源程序中的切入点进行匹配，切入点是对符合特定条件的一类接入点的抽象化描述，切入点包括代码静态结构中的特定位置或程序执行流程中的特定时刻，对于面向切面编程（AOP）来说，需要在特定的切入点执行特定的通知目标代码，所以要实现切面代码中的切入点和程序中的接入点的匹配。AC++工具首先利用puma编译器编译源文件生成抽象语法树，在抽象语法树的基础上，根据所支持的切入点种类，找出所有可能的根据其所支持的切入点种类，找出所有可能的接入点，在知识库中记录接入点的类型，名称，参数，所在文件位置等相关信息，这样在后续的匹配过程中，便可以直接将切入点和知识库进行匹配，这种匹配方式通过知识库避免同一个文件多次匹配带来的重复编译，提高了重用性，然后通过将知识库中的连接点和切面文件中的切入点进行匹配，在匹配的代码位置插入相应的横切关注点代码。在完成对源程序的每个文件插桩后，整个织入过程结束，得到插桩后的源程序。

步骤五：修改SystemC仿真内核，使其适用于运行时验证。要实现程序的运行时监测，监视器需要实时监控SystemC内核状态，要想实现内核状态的监控，一种方法是实现一个返回当前执行内核相关数据的API，另一种方式是修改内核以发送有关信息。在本实施例中选择第二种方法，在函数调用时内核发送状态更新信息，监视器被触发并在到达相关采样点后执行监测。为了尽可能少的添加代码，在内核代码中封装了具有相应功能的新对象Observer，Observer存储对监视器的引用，接收内核状态的更新，然后通知需要在当前采样点执行的监视器。

步骤六：安装SystemC类库及仿真内核，使用gcc编译器对插桩后的SystemC程序进行编译，生成可执行的SystemC模型。SystemC是基于C++的编程语言，它在C++的基础之上增加了一些重要概念，如并发（多个处理器同时执行）、定时事件和数据类型等概念，SystemC还增加了一个由使用合法C++代码编写的函数、数据类型和其他语言结构函数所组成的类库，该类库提供了功能强大的新机制，可以为具有硬件时序、并发和响应行为的系统结构建模。除了增加SystemC的类库外，还需要安装仿真内核，基于仿真内核可以编写SystemC代码来描述设计或系统规范，并对其进行仿真。因为SystemC就是C++，所以可以使用标准的C++编程语言和开发工具，对其进行仿真调试和研究。

步骤七：监视器基于SystemC模型的运行轨迹来验证源程序是否满足所要求的安全规范。根据形式化定理：任意的LTL公式都有一个语言等价的有限状态自动机，这意味着验证一个无限序列是否满足LTL公式的问题可以转化为该序列是否被对应的有限状态自动机接受的问题。因此依据步骤三生成的监视器文件对程序运行轨迹进行验证，该监视器是有限状态自动机的具体实现，其自动机的字母表为程序运行的基本事件，由基本事件组成程序的运行轨迹作为监视器的输入，当运行轨迹一直可以被对应自动机接收时，证明程序满足该性质。若出现轨迹不被接收的情况时证明程序运行轨迹不满足安全规范，根据配置文件里的记录参数对不满足安全规范的路径进行记录。

实施例1

本具体实施例以生产者消费者程序为例，对其所要满足的安全规范进行运行时验证。对于生产者消费者程序而言，生产者向缓冲区存放数据，消费者从缓冲区读取数据，消费者在读取数据的过程中要保证数据的完整性。在本实施例中生产者向缓冲区内存放字符串，消费者读取字符串，需要满足的安全规范是消费者所读取的字符串是完整的，即程序在运行过程中不能出现只读取部分字符串的情况。

本具体实施例中，运用本发明的针对SystemC程序运行时验证方法对生产者消费者程序所需满足的安全规范进行验证，其具体步骤如下：

步骤一：分析生产者消费者程序所需满足的安全规范。根据生产者消费者的功能需求，总结出了以下安全规范：消费者必须读取完整字符串，不能出现遗漏字符或读取出错的情况。

在安全规范中，使用LTL线性时序逻辑表达式对安全规范进行刻画，对于消费者读取字符串的安全规范，首先要明确字符串的首字符，根据字符串长度与内容，限定在一定时间内读取到字符串尾字符，从而保证读取字符串的完整性。

步骤二：编写配置文件。

第一步：指定监视器文件的输出路径；

第二步：指定监视器文件名称；

第三步：声明源程序中被监视类，在这里分别是生产者Producer类与消费者Consumer类；

第四步：声明指向被监视类的指针，使用该指针可以指向生产者类与消费者类中被监视的成员变量；

第五步：声明被监视变量，并指定监视器中的变量来存储被监视变量的值；

第六步：声明监视类中监视变量的类型；

第七步：指定监视器获取监视变量值的时间段；

第八步：将步骤一中安全规范的LTL线性逻辑表达式写入配置文件；

第九步：声明需要包含的头文件，在本实例中为生产者类与消费者类的头文件；

配置文件根据不同策略参数会有所不同，用户可根据需求选择不同验证策略。

步骤三：根据配置文件使切面类及监视器生成工具自动生成切面类与监视器，命令格式如下：tim -conf path ，path为配置文件路径。

步骤四：使用AC++工具对生产者消费者源程序进行插桩。使用AC++工具命令对源程序每个文件进行插桩，命令格式如下：

ac + + -c SOURCE_HOME/file name

-o TARGET_HOME/file name

-p SOURCE_HOME/ - I SOURCE_HOME

-I SYSTEMC_HOME/include

- - config ASPECTC_HOME/puma.config

SOURCE_HOME参数为源文件路径，TARGET_HOME参数为插桩后程序的输出路径，

SYSTEMC_HOME参数为SystemC类库安装路径，ASPECTC_HOME参数为切面类文件路径。

步骤五：修改SystemC仿真内核，首先新建mon_observer类，定义相关成员变量及成员函数，在sc_simcontext.h头文件中声明mon_observer类，并将其声明为sc_simcontext类的友元类，声明指向mon_observer类的指针observer，在sc_simcontext.cpp文件中，使用指针observer在内核状态变化点调用相应函数。

步骤六：安装SystemC类库及仿真内核，使用gcc编译生产者消费者源程序，生成可执行文件。

步骤七：运行可执行文件，使用监视器监视程序运行情况，最终验证了消费者程序正确读取了字符串。

实施例2

本具体实施例以ALU算术逻辑单元程序为例，对其所要满足的安全规范进行运行时验证。算术逻辑单元程序根据指定操作数以及操作码计算出结果并进行输出，在除法操作中若除数为零，则需要及时发现运算出错的情况。在本实施例中监视器需要监视除法操作中除数值，若出现除数为零的情况，要及时报错，防止导致严重后果。

本具体实施例中，运用本发明的针对SystemC程序运行时验证方法对ALU算术逻辑单元程序所需满足的安全规范进行验证，其具体步骤如下：

步骤一：分析算术逻辑单元程序所需满足的安全规范。根据计算要求，总结出了以下安全规范：算术逻辑单元在进行除法操作时，需要及时报错，不能出现误报以及漏报情况。

在安全规范中，使用LTL线性时序逻辑表达式对安全规范进行刻画，对于除法操作的安全规范，首先要明确除法操作中存储除数的变量，根据变量内容，当出现为零情况时检查程序状态寄存器的值是否设为为零状态码，从而保证计算过程的正确性。

步骤二：编写配置文件。

第一步：指定监视器文件的输出路径；

第二步：指定监视器文件名称；

第三步：声明源程序中被监视类，在这里分别是算术逻辑单元类；

第四步：声明指向被监视类的指针，使用该指针可以指向被监视的操作数变量；

第五步：声明被监视变量，并指定监视器中的变量来存储被监视变量的值；

第六步：声明监视类中监视变量的类型；

第七步：指定监视器获取监视变量值的时间段；

第八步：将步骤一中安全规范的LTL线性逻辑表达式写入配置文件；

第九步：声明需要包含的头文件，在本实例中为定义汇编系统指令的头文件；

配置文件根据不同策略参数会有所不同，用户可根据需求选择不同验证策略。

步骤三：根据配置文件使切面类及监视器生成工具自动生成切面类与监视器，命令格式如下：tim -conf path ，path为配置文件路径。

步骤四：使用AC++工具对生产者消费者源程序进行插桩。使用AC++工具命令对源程序每个文件进行插桩，命令格式如下：

ac + + -c SOURCE_HOME/file name

-o TARGET_HOME/file name

-p SOURCE_HOME/ - I SOURCE_HOME

-I SYSTEMC_HOME/include

- - config ASPECTC_HOME/puma.config

SOURCE_HOME参数为源文件路径，TARGET_HOME参数为插桩后程序的输出路径，

SYSTEMC_HOME参数为SystemC类库安装路径，ASPECTC_HOME参数为切面类文件路径。

步骤五：修改SystemC仿真内核，首先新建mon_observer类，定义相关成员变量及成员函数，在sc_simcontext.h头文件中声明mon_observer类，并将其声明为sc_simcontext类的友元类，声明指向mon_observer类的指针observer，在sc_simcontext.cpp文件中，使用指针observer在内核状态变化点调用相应函数。

步骤六：安装SystemC类库及仿真内核，使用gcc编译算术逻辑单元源程序，生成可执行文件。

步骤七：运行可执行文件，使用监视器监视程序运行情况，最终验证程序正确处理了除数为零的情况。

图2为针对SystemC程序的运行时验证方法中自运行时验证系统设计图，在插桩后的SystemC源程序运行过程中，当监视的变量发生变化时会生成事件，该事件会被监视器的事件接收器所接收，监视器使用性质验证器对接收到的事件进行验证，判断事件是否违背性质，若事件违背性质（安全规范），则产生相应的反馈如报告程序出错。

图3为本发明针对SystemC程序的运行时验证方法的工作流程图，首先用户使用线性时序逻辑（LTL）表达式描述系统所需满足的安全规范，同时定义切面类以及文件及监视器文件自动生成工具所需参数编写配置文件，接下来通过配置文件与LTL线性逻辑表达式生成检测程序性质的切面类以及监测程序运行状态的监测器，接下来通过AC++工具将切面类织入源程序，生成插桩后的源程序，最后通过在SystemC仿真内核上运行插桩后的源程序实现对程序的运行时验证。

本发明的保护内容不局限于以上实施例。在不背离发明构思的精神和范围下，本领域技术人员能够想到的变化和优点都被包括在本发明中，并且以所附的权利要求书为保护范围。

Claims (8)

1.一种针对源代码的运行时形式化验证方法，其特征在于，包括以下步骤：

步骤一：根据源程序的需求规范，提取源程序所需满足的安全规范，使用LTL线性时态逻辑对安全规范进行刻画，并指定所需参数；

步骤二：根据提取的所述安全规范以及指定的所需参数编写配置文件；

步骤三：根据所述配置文件使用运行时验证工具自动生成相应的监视器文件以及切面类文件；

步骤四：使用工具将切面类文件置入源程序，生成插桩后的源程序；步骤D1：使用插桩工具生成puma.config文件，用于编译器进行预处理，生成代码连接点的知识库；

步骤D2：将生成的切面类文件移动到源程序所在的路径下，插桩工具根据知识库中的连接点和切面文件中的切入点将横切关注点代码插入源程序；

步骤五：修改仿真内核，使其适用于运行时形式化验证方法；

步骤E1：修改内核中的上下文调度函数；

步骤E2：修改内核中状态转换函数；

步骤六：编译插桩后的源程序和监视器文件并执行，得到运行轨迹，使用监视器对得到的运行轨迹进行验证；

步骤七：根据验证结果判断插桩后的源程序是否满足性质；若不满足性质，对相应的运行轨迹进行记录或者进行程序自动修复；若满足性质，则继续监视程序的运行。

2.如权利要求1所述的针对源代码的运行时形式化验证方法，其特征在于，所述步骤一包括以下步骤：

步骤A1：根据对源程序需求规范的分析，提取所需满足的安全规范，使用LTL线性时态逻辑来描述验证性质，得到其逻辑公式；

步骤A2：声明源程序中要监测的类，并定义相应的数据结构指向监测变量以及提取变量的时序关系。

3.如权利要求2所述的针对源代码的运行时形式化验证方法，其特征在于，所述步骤一中，所述LTL线性时态逻辑公式用来表示源程序中变量之间的时序关系。

4.如权利要求1所述的针对源代码的运行时形式化验证方法，其特征在于，所述步骤二中，所述编写配置文件的步骤具体包括：

步骤B1：指定配置文件的输出路径；

步骤B2：指定配置文件名称；

步骤B3：声明源程序中被监视类；

步骤B4：声明指向被监视类的指针，使用该指针可以指向被监视的成员变量；

步骤B5：声明被监视变量，并指定监视器中的变量来存储被监视变量的值；

步骤B6：声明监视类中监视变量的类型；

步骤B7：指定监视器获取监视变量值的时间段；

步骤B8：将所述步骤一中安全规范的LTL线性时态逻辑公式写入配置文件；

步骤B9：声明需要包含的头文件。

5.如权利要求1所述的针对源代码的运行时形式化验证方法，其特征在于，所述步骤三包含以下步骤：

步骤C1：运用本项目开发人员编写的工具，读取配置文件；

步骤C2：将配置文件中的安全规范的LTL线性时态逻辑公式转换成监视器；

步骤C3：将配置文件中的需要监视的变量转换成切片类。

6.如权利要求1所述的针对源代码的运行时形式化验证方法，其特征在于，所述步骤六包括以下步骤：

步骤F1：运行插桩后的源程序，得到运行到当前时刻的运行轨迹；

步骤F2：将运行轨迹传输给监视器，通过监视器监视运行轨迹，验证性质。

7.如权利要求1所述的针对源代码的运行时形式化验证方法，其特征在于，所述步骤七包括以下步骤：

步骤G1：若验证正确，则继续监视源程序的运行；

步骤G2：若该运行轨迹不满足性质，在记录该运行轨迹或采用程序自修复功能，再继续运行。

8.如权利要求1所述的针对源代码的运行时形式化验证方法，其特征在于，所述源程序是SystemC源代码、C源代码或C++源代码。

Images