符合ARINC653标准的操作系统形式化验证方法

技术领域

本发明属于操作系统验证领域，尤其涉及一种符合ARINC653标准的操作系统形式化验证方法。

背景技术

操作系统内核在处理器上工作时，能够以最高权限直接访问硬件，操作系统上任何故障或失误都可能导致计算机系统崩溃，因此保障操作系统的安全性和可靠性具有重要价值。

ARINC653主要阐述了模块化航空设备的操作环境，描述了嵌入式航空软件运行时的环境，该标准已经广泛应用于综合航空电子系统中，对确保操作系统的安全具有重要意义。

在操作系统中形式化验证指的是使用数学方法证明系统符合某些特定的性质，确保系统的可靠性。随着定理证明工具功能的更加强大，以及形式化验证理论和框架的日渐完善，操作系统的形式化建模与验证方向虽然取得了一定的进展，但仍存在不少问题。

操作系统大多由C语言嵌套汇编语言实现，各个模块之间复杂的调度操作更增加了操作系统进行形式化建模的难度，目前大多数形式化方法对操作系统建模时，将模型分为三个层次，需求层、设计层和代码层，需求层仅关注系统功能需求和安全需求方面的实现情况，设计层关注系统各类算法是否正确，代码层则关注系统实现代码的正确性。其中，虽然有很多方法能够对设计层的建模，但是很少有方法能够处理源代码中的指针变量和循环函数，建模完成后，模型的验证也是一个庞大的工作。

发明内容

本发明的目的在于针对现有验证方法安全性的不足，提供一种符合ARINC653标准的操作系统形式化验证方法，使用python语言对操作系统建模，不仅在建模时能够利用python丰富的库函数在模型中模拟源代码中的指针变量和循环函数，在验证阶段调用z3求解器高效验证系统相关性质，以形式化方法为操作系统提供可靠性；还能在验证时遵循Arinc653规范，以此保障操作系统的安全性。

根据本申请实施例的第一方面，提供一种符合ARINC653标准的操作系统形式化验证方法，包括：

(1)建立目标操作系统的形式化模型：基于所要验证的操作系统的源代码，使用python语言和z3库函数构建系统的数据结构、类函数，修改所述源代码中的服务函数，向所有服务函数中添加相应的符号执行操作以模拟系统状态变迁过程，从而完成整个操作系统的形式化建模；

(2)规范性质验证：基于ARINC653标准得到所有服务的前提条件和预期结果，并将其转换为形式化语言，在步骤(1)得到的形式化模型中调用z3求解器并将转换后的服务的前提条件和预期结果加入z3求解器中，根据求解结果验证系统是否满足相应的规范性质。

进一步地，步骤(1)包括：

(1.1)根据所述源代码中的数据字节大小，建立相应的位向量以表示对应的数据结构；

(1.2)根据步骤(1.1)中构建的数据结构，构建类函数以表示系统的各模块；

(1.3)根据步骤(1.1)中构建的数据结构和步骤(1.2)构建的类函数，改写操作系统源代码中的服务函数并添加相应的符号执行操作以模拟系统状态变迁过程，以使得所述服务函数的输入输出的变量类型都是基于z3构造的，且所述服务函数能够处理函数中的指针和循环。

进一步地，(1.1)中，指针采用64位向量表示，其余数据结构采用32位或64位向量表示。

进一步地，(1.2)中，类的内部字段由python的Map函数建立变量名称与变量数据类型之间的映射关系。

进一步地，(1.3)中，向所述服务函数中加入系统状态，并根据服务函数中的执行条件添加符号执行操作：

s＝IF(cond,s1,s2)

其中s表示系统初始状态，IF函数为z3的判断函数，cond为判断条件，s1和s2分别代表不同的系统状态，当cond为真时，符号执行后状态s变迁为s1，否则变迁为s2。

进一步地，步骤(2)包括：

(2.1)基于ARINC653标准，提取标准中服务错误运行和正常运行的前提条件和预期结果；

(2.2)在步骤(1)得到的形式化模型中，初始化z3求解器并将步骤(2.1)得到的前提条件和验证结果在验证函数中用形式化语言描述；

(2.3)基于步骤(2.2)得到的形式化语言描述的前提条件和验证结果，将其按照ARINC653标准中的验证顺序，将每一组的前提条件和按布尔逻辑取反的验证结果加入z3求解器中进行求解，若求解结果为unsat则表示验证成功，若为sat，则根据求解结果返回的反例修改模型，直到验证成功。

进一步地，在(2.2)中，将前提条件和对应的预期结果用python描述相应的语义并在z3中进行验证，若验证通过则成功用形式化语言描述。

进一步地，在(2.3)中，验证完一组前提条件和预期结果后，重置z3求解器，继续验证下一组，直至提取的所有前提条件和预期结果都得到验证。

根据本申请实施例的第二方面，提供一种电子设备，包括：

一个或多个处理器；

存储器，用于存储一个或多个程序；

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如第一方面所述的方法。

根据本申请实施例的第三方面，提供一种计算机可读存储介质，其上存储有计算机指令，该指令被处理器执行时实现如第一方面所述方法的步骤。

本发明的技术方案概括为：

1、提出了一种操作系统形式化建模方法。基于操作系统源代码，通过创建的BaseStruct类构建模型的数据结构，内部字段用Map函数建立映射关系，整个系统状态用一个类表示，将其他所有的类将会在表示系统状态的类中初始化，完成系统的状态建模，最后构建系统服务行为对应的函数，完成整个系统的形式化建模；

2、提出了一种操作系统形式化验证方法。基于ARINC653标准，分析系统执行服务的状态变迁过程，得到验证的前提条件集合prev和预期结果集合post，将其转换为形式化语言后将相应的前提条件prev和布尔逻辑取反的预期结果Not(post)放入z3求解器中求解，结果为unsat则表明该性质验证成功，结果为sat则根据返回的可行解找出错误；所有对应的前提条件和预期结果都得到验证后完成系统形式化验证过程。

本申请的实施例提供的技术方案可以包括以下有益效果：

由上述实施例可知，本申请应用python和z3库模拟指针变量和循环函数，使得构建的设计层形式化模型更贴合实际的操作系统。本发明首次提出了符合ARINC653标准的操作系统形式化建模与验证方法，形式模型中模拟了源代码的指针和循环函数，建模方法优于现有方法的同时确保模型符合ARINC653标准，保障了系统的安全性。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

图1是根据一示例性实施例示出的一种符合ARINC653标准的操作系统形式化验证方法的流程图。

图2是建立目标操作系统的形式化模型的状态图。

图3是RELEASE_MUTEX服务函数的设计思路示意图。

图4是基于ARINC653的形式化模型验证过程的示意图。

图5是根据一示例性实施例示出的一种符合ARINC653标准的操作系统形式化验证装置的框图。

图6是根据一示例性实施例示出的电子设备的示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。

在本申请使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

如图1所示，本申请提出了一种符合ARINC653标准的操作系统形式化验证方法，该方法包括以下步骤：

(1)建立目标操作系统的形式化模型：基于所要验证的操作系统的源代码，使用python语言和z3库函数构建系统的数据结构、类函数，修改所述源代码中的服务函数，向所有服务函数中添加相应的符号执行操作以模拟系统状态变迁过程，从而完成整个操作系统的形式化建模；如图2所示，其中S为系统初始状态，Func为系统各个服务，Cond为状态转换条件，S1，S2表示状态变迁过程中一系列中间状态，S’表示服务完成后的最终状态，利用z3和符号执行构建系统状态变迁过程的其他确定状态，这些状态涵盖了所有可达状态集合。具体包括以下子步骤：

(1.1)根据所述源代码中的数据字节大小，建立相应的位向量以表示对应的数据结构；

具体地，基于python的z3库构建系统的数据结构。本模型的数据结构都用位向量表示，z3库中自带的BitVecSort函数能够生成指定字节的位向量，因此根据源代码的数据字节大小，即可建立相应的位向量表示的数据结构。

模型中的数据结构一般用32位向量或64位向量表示，其中指针LOCATOR＝z3.BitVecSort(64)，用唯一的64位向量表示变量存放的内存地址。

(1.2)根据步骤(1.1)中构建的数据结构，构建类函数以表示系统的各模块；

具体地，基于python构建系统的类函数。系统的各个模块用不同的类表示，类内部字段用Map函数实现，即根据源代码的变量名称和数据类型，在形式模型中使用步骤(1.1)得到的数据结构，建立变量名称与类型的映射关系如下所示：

Variable_name＝Map(LOCATOR,variable_type)

其中Variable_name为变量名称，Map为z3的映射函数，LOCATOR为指针，variable_type为数据类型。映射关系一般通过指针与数据类型构建，根据实际使用情况可以改变Map函数中变量个数建立其他映射关系。

(1.3)据步骤(1.1)中构建的数据结构和步骤(1.2)构建的类函数，改写操作系统源代码中的服务函数(即与ARINC653服务标准相关的函数)并添加相应的符号执行操作以模拟系统状态变迁过程，以使得所述服务函数的输入输出的变量类型都是基于z3构造的，且所述服务函数能够处理函数中的指针和循环；

具体地，基于系统源代码，分析服务函数的设计思路并构建形式化模型。使用步骤(1.1)和步骤(1.2)得到的数据结构和类函数，改写源代码中的服务函数，使得形式模型中服务函数的输入输出的变量类型都是基于z3构造的，以便在后续的验证过程中能够直接使用z3求解器对相应的函数进行操作；以ARINC653标准中CREATE_PROCESS服务为例给出改写示例1，源代码中对应的mx_process_create函数部分代码如下所示：

向mx_process_create函数增加输入输出变量state，用于获取系统执行该函数前后的状态，在系统状态state中添加state.return.value便于从系统状态中直接获取函数返回值，用locator_attribute表示指向attribute的指针，用符号执行代替源代码中的if判断，改写后的mx_process_create函数部分代码如下所示：

def mx_process_create(state,locator_attribute,argument):

state.return_code.value＝NO_ERROR

attributes＝state.process_attribute[locator_attribute]

cur_partition＝state.mx_vcpu[state.mx_cpus[state.current_cpu].current_vcpu].partition

current_partition＝state.partition[cur_partition]

cond＝z3.ULE(state.partition_config[current_partition.config].limit_processes,current_partition.nb_processes)

state.return_code.value＝util.If(cond,INVALID_CONFIG,state.return_code.value)

state.return_code.value,state＝MX_PROCESS_ENTRY_POINT_CHECK(state,cur_partition,attributes.entry_point,INVALID_PARAM)

old＝copy.deepcopy(state)

process,state＝_mx_process_find_by_name(state,cur_partition,attributes.name)

cond2＝z3.And(state.return_code.value＝＝NO_ERROR,process！＝MX_NULL)

state.return_code.value＝util.If(cond2,NO_ACTION,old.return_code.value)

......

return state.return_code.value,process_id,state

z3自带的递归函数无法处理带有循环的函数，用循环不变式的方式处理循环函数在验证时无法证明，因此利用z3的一些基本库函数自定义了Loop函数，用于处理源代码中带有循环的函数，函数定义如下：

Loop(state,cond,f,solver,res,*i)

其中Loop为函数名称，state为系统状态，cond是循环中止条件，f是循环结构体，solver是z3求解器的实例，可以向其中加入条件限制循环次数，res是循环结构的初始返回值，i是循环自变量，可以引入多个循环自变量。以下给出改写示例2：

mx_process_create函数中的MX_PROCESS_ENTRY_POINT_CHECK函数在检查进程入口点时涉及循环，部分子代码如下：

其中，循环自变量为i，初始值为0，终止条件为i小于nb_elf_segments或入口点地址在系统elf文件对应的虚拟地址范围内，改写后的函数如下所示：

基于ARINC653标准和源代码，向所有服务函数中添加相应的符号执行操作以模拟系统状态变迁过程；

模拟系统状态变迁过程：系统整体状态用特殊的类state表示，内部字段为步骤(1.2)中类的构造函数，即该类包含其他类函数的初始化过程，向步骤(1.3)得到的服务函数中加入系统状态，并根据函数中的执行条件添加符号执行操作：

s＝IF(cond,s1,s2)

其中s表示系统初始状态，IF函数为z3的判断函数，cond为判断条件，s1和s2分别代表不同的系统状态，当cond为真时，符号执行后状态s变迁为s1，否则变迁为s2。将步骤(1.3)中所有的服务函数都添加相应的符号执行操作后，完成系统状态变迁的建模过程

改写示例2中将源代码中if判断用符号执行代替。

以下给出RELEASE_MUTEX服务函数的设计思路，如图3所示，start和end分别表示函数开始和结束状态，mutex表示系统进程锁，该服务的功能是为当前进程其释放一次进程锁互斥量，如果释放后，还有其他进程锁存在，则不进行其他操作，若无其他进程锁，则重置进程锁状态，最后判断进程锁等待队列中是否存在其他进程，若无，则不进行其他操作，若有，将队列中第一个进程上锁然后重新调度该进程。RELEASE_MUTEX服务返回值及说明如下表1所示。

表1 RELEASE_MUTEX服务返回值及说明

改写思路：向RELEASE_MUTEX函数添加输入变量state，作为系统整体状态变量，state类中有return_code参数保存函数返回值便于后续验证，源代码中if等判断语句用符号执行代替，for等循环语句用Loop进行改写，最后添加输出变量state和state.return_code.value，上述过程中涉及数据的数据结构均由步骤(1.1)和(1.2)中数据构成。

按如上方法，即得到了目标系统基于python和z3的形式化模型。

(2)基于ARINC653的形式化模型验证过程：基于ARINC653标准得到所有服务的前提条件和预期结果，并将其转换为形式化语言，在步骤(1)得到的形式化模型中调用z3求解器并将转换后的服务的前提条件和预期结果加入z3求解器中，根据求解结果验证系统是否满足相应的规范性质；如图4所示(图中solver为z3求解器)，具体包括以下子步骤：

(2.1)基于ARINC653标准，提取标准中服务错误运行和正常运行的前提条件和预期结果；

基于ARINC653标准，提取各个服务的前提条件集合prev和预期结果集合post。首先，根据标准中服务的运行说明，将可能的错误运行原因加入prev集合，将错误运行后相应的程序的返回值加入post集合，然后分析系统运行服务过程中状态的变化，将系统初始状态加入prev集合，将完成服务后的系统状态加入post集合。

(2.2)在步骤(1)得到的形式化模型中，初始化z3求解器并将步骤(2.1)得到的前提条件和验证结果在验证函数中用形式化语言描述；

具体地，基于z3求解器，将前提条件和对应的预期结果用python描述相应的语义并在z3中进行验证。例如CREATE PROCESS服务中一组前提条件和预期结果为：如果已创建的进程数量达到上限，则返回错误代码INVALID_CONFIG。其中，前提条件：已创建的进程数量达到上限用prev表示，prev＝

z3.ULE(old_s.partition_config[current_partition.config].limit_processes,current_partition.nb_processes)

预期结果：返回错误代码INVALID_CONFIG用post表示，post＝

ret＝＝dt_des.INVALID_CONFIG

在步骤(1)得到的形式化模型中初始化z3求解器，将步骤(2.1)得到的prev集合中某个服务的第一个前提条件转换为形式化语言得到prev1，在post集合中找到prev1对应的预期结果转换为形式化语言得到post1；

(2.3)基于步骤(2.2)得到的形式化语言描述的前提条件和验证结果，将其按照ARINC653标准中的验证顺序，将每一组的前提条件和按布尔逻辑取反的验证结果加入z3求解器中进行求解，若求解结果为unsat则表示验证成功，若为sat，则根据求解结果返回的反例修改模型，直到验证成功；

将prev1和布尔逻辑取反的Not(post1)依次放入z3求解器中进行求解，若求解结果为unsat，则表明该性质验证成功，若求解结果为sat则表明该性质验证失败，根据返回的一条可满足解找到并解决问题，验证完一组前提条件和预期结果后，重置z3求解器，将该服务发第二个前提条件转换为形式化语言得到prev2，同理在post集合中得到对应的post2，将该服务之前验证过的所有前提条件布尔逻辑取反后加入z3求解器，本处此前仅验证过一个prev1，因此将Not(prev1)加入z3求解器中，然后将prev2和Not(post2)加入求解器中求解，重复上述前提条件和预期结果组合的验证过程，直到服务中所有的前提条件和对应的预期结果都得到验证，即为完成单个服务的验证，按照ARINC653标准将所有服务的前提条件和预期结果验证后完成整个模型的形式化验证。这样设计的目的在于，如果模型不满足相应的前提条件和预期结果，能够快速生成一个反例供验证者参考，提高验证速度

与前述的符合ARINC653标准的操作系统形式化验证方法的实施例相对应，本申请还提供了符合ARINC653标准的操作系统形式化验证装置的实施例。

图5是根据一示例性实施例示出的一种符合ARINC653标准的操作系统形式化验证装置的框图。参照图5，该装置可以包括：

形式化模型建立模块21：基于所要验证的操作系统的源代码，使用python语言和z3库函数构建系统的数据结构、类函数，修改所述源代码中的服务函数，向所有服务函数中添加相应的符号执行操作以模拟系统状态变迁过程，从而完成整个操作系统的形式化建模；

规范性质验证模块22：基于ARINC653标准得到所有服务的前提条件和预期结果，并将其转换为形式化语言，在步骤(1)得到的形式化模型中调用z3求解器并将转换后的服务的前提条件和预期结果加入z3求解器中，根据求解结果验证系统是否满足相应的规范性质。

关于上述实施例中的装置，其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述，此处将不做详细阐述说明。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本申请方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

相应的，本申请还提供一种电子设备，包括：一个或多个处理器；存储器，用于存储一个或多个程序；当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如上述的符合ARINC653标准的操作系统形式化验证方法。如图6所示，为本发明实施例提供的一种符合ARINC653标准的操作系统形式化验证方法所在任意具备数据处理能力的设备的一种硬件结构图，除了图6所示的处理器、内存以及网络接口之外，实施例中装置所在的任意具备数据处理能力的设备通常根据该任意具备数据处理能力的设备的实际功能，还可以包括其他硬件，对此不再赘述。

相应的，本申请还提供一种计算机可读存储介质，其上存储有计算机指令，该指令被处理器执行时实现如上述的符合ARINC653标准的操作系统形式化验证方法。所述计算机可读存储介质可以是前述任一实施例所述的任意具备数据处理能力的设备的内部存储单元，例如硬盘或内存。所述计算机可读存储介质也可以是外部存储设备，例如所述设备上配备的插接式硬盘、智能存储卡(Smart Media Card，SMC)、SD卡、闪存卡(Flash Card)等。进一步的，所述计算机可读存储介还可以既包括任意具备数据处理能力的设备的内部存储单元也包括外部存储设备。所述计算机可读存储介质用于存储所述计算机程序以及所述任意具备数据处理能力的设备所需的其他程序和数据，还可以用于暂时地存储已经输出或者将要输出的数据。

本领域技术人员在考虑说明书及实践这里公开的内容后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。