形式化验证操作系统
形式化验证seL4操作系统
王俊超
摘要：完全的形式化验证是确保系统不会出现编程和设计错误的唯一方法。本文假设编译器，汇编代码和硬件层都是正确的，在此基础之上介绍了对seL4内核从抽象规约层到C语言实现层的形式化机器验证。目前为止，seL4是第一个经过形式化验证并证明功能正确性的完整的通用的操作系统内核。这里所指的功能性是说实现总是严格的满足上一抽象层内核行为的规约。本文证明了seL4操作系统在任何情况下都不会崩溃以及执行不安全的操作，更重要的是，可以精确的推断出seL4在所有情况下的行为。
关键词：seL4；形式化验证；操作系统
1.引言
操作系统的可靠性和安全性几乎与计算机系统等价，因为内核可以在处理器的最高权限上工作，可以随意的访问硬件。因此，操作系统内核实现出现的任何一个微小的错误都会导致整个计算机系统的崩溃。
为了保证操作系统的安全性，传统的一些做法有减少高权限的代码的数量，从而避免bug出现在较高的权限层内。那么，如果代码的数量较少，便可以通过形式化的机器验证方法来证明内核的实现满足规约，并且在实现时不会有程序员由于编码引入的实现漏洞。
本文通过机器检验的形式化证明验证了seL4的功能正确性，目前，seL4所能达到的功能如下：
能够在现实生活中使用，并且其性能与当前性能最好的微内核相当；其行为在抽象层进行了精确的规约；其形式化设计用来证明一些需要的属性比如中断等的安全性；其实现满足规约；访问控制机制能够保证高强度的安全性。
目前，seL4是第一个被完全形式化验证其功能正确性的操作系统内核，所以，它是一个前所未有的具有高度安全性和可靠性的底层系统级平台。
在本文所描述的功能正确性要比模型检验、静态分析以及采用类型安全编程语言实现的内核要强的多。本文不仅对内核的规约层面进行了分析，同时也对于内核的精细的行为进行了规约和验证。
此外，本文还创立了一套融合了传统操作系统研发技术和形式化方法技术，用来快速实现内核设计与实现的方法学，经过实践证明，利用这套方法学开发出的操作系统不仅在安全性上有着充分的保障，在性能上也不会受到影响。
2.研究现状
UCLA Secure Unix和Provably Secure Operating System (PSOS)在十九世纪七十年代末第一次尝试着来验证操作系统内核。本文借鉴了UCLA的功能正确性的验证思路。UCLA项目完成了90%的规约和20%的验证，最终得出了不变式的推理占据了证明的大部分时间，在本文的项目中这一点也得到了证实。
PSOS主要关注于内核设计的形式化验证，然而，却从来没有完成过大量的实现证明。他们的设计方法学被Ford Aerospace的Kernelized Secure Operating System (KSOS) 、Secure Ada Target(SAT)以及Logical Coprocessor Kernel (LOCK)所采用。
第一个实际的完整的证明是由KIT实现的。然而，其实现针对的对象是一个高度理想化的操作系统内核，并不能在实际的机器上运行。
Bevier和Smith随后将Mach的内核进行了形式化，但是并没有提供其实现的证明。其他的一些关于操作系统内核的形式化建模和证明都没有在实现层进行验证，包括EROS内核，基于FLASK的SELinux内核等。
VFiasco项目和气候的Robin项目尝试验证C++的内核实现。他们能够创建大量的基于C++实际代码的模型，然而在形式化验证方面并没有做太多的工作。
Heitmeyer et al声称验证和标准化了一个名为LOC的嵌入式操作系统，然而，实际上他们的工作并未达到C代码层面的验证，与功能性验证差距较远。
比较新的一个项目是Verisoft，他们尝试验证操作系统的内核和从硬件到应用程序的完整的软件栈。这里面包含了类似于Pascal语言的已经验证过的编译器，这个编译器并不做任何优化处理。虽然这个项目目前还没有完成，但是，却证实了功能性验证软件栈的目标是可以实现的。同时，他们也证明了形式化验证汇编一级的代码是可以实现的。不幸的是，他们的工作是基于VAMP硬件平台，该硬件平台并不被广泛使用。本文提到的seL4操作系统针对的是ARM6平台，目的是实现一个可用的真实的内核。
其他用于提高操作系统可靠性的形式化技术包括静态分析，模型检验和形态分析。静态分析在最好的情况下仅仅能检测出类中内存的泄露。模型检验能够验证实际的C代码中的某些安全特性比如系统调用等。然而，这些自动验证技术远远不能满足功能正确性的需求。
采用类型安全的语言比如SPIN和Singularity能够增强可靠性，然而，如果用这些语言来实现原系统的运行状态。虽然类型安全是一个比较不错的性质，但是还是不够强烈，因为内核仍然会出现异常比如null指针的问题。在本文中，验证了seL4代码的类型安全性。3.实现原理
3.1 seL4简介
seL4是一个第三代的基于L4的操作系统内核。L4是一组基于微内核构架的操作系统内核，澳大利亚研究组织NICTA创造了一个新的L4版本，称为Secure Embedded L4（简写seL4），宣布在世界上率先开发出第一个正规机器检测证明（formal machine-checked proof）通用操作系统。
seL4微内核设计针对实时应用，可潜在应用于强调安全和关键性任务的领域内，如军用和医疗行业。形式证明在较小的内核中已经实现，但这次是首次在执行复杂任务的操作系统内核中实现。研究发现常用的攻击方法对seL4无效，如恶意程序经常采用的缓存溢出漏洞。Open Kernel Labs首席科学家和NICTA的ERTOS Group负责人Gernot Heiser教授表示实现许多人认为不可能实现的任务是令人兴奋的。他表示暂时还没有产品开发计划。
3.2 seL4设计
通过高效的管理和使用硬件资源，可以带来直接的性能提升，因此，操作系统开发者倾向于自底向上的内核开发方法。与此不同的是，形式化方法更倾向采用一种自顶向下的设计方法。这种开发方法的源头是一个高度抽象的模型。本文基于上述的两种开发方法，并做了一个折中，用面向过程的Haskell语言实现了一个内核原型。
Figure 1详细了描述了该方法。上图中整个大的矩形是形式化验证使用的所有模型。双箭头代表了实现或者证明。中间是实现的Haskell原型。该原型需要设计和实现相关的算法来得到底层的硬件细节。为了运行这一原型代码，本文使用了从QEMU中抽取出来的虚拟化平台。因此，所有的仿真操作能够完整的表现出来操作系统的各种行为。
虽然Haskell代码是一个可执行的接近于最终实现的代码，但是，并不是最终的C代码。因此，我们人工的用C语言重新对内核进行了实现。首先，Haskell的运行环境包含了大量的难以验证的代码。第二，Haskell的代码依赖于内存回收机制，这种机制使其难以在实际应用环境中使用。此外，使用C可以在底层的实现中进行优化。虽然可以直接从Haskell代码编译成C代码，但是，这样会使得系统的性能受到影响。
3.3 seL4的形式化验证
本文所采用的形式化验证方法是交互式机器协助定理证明，使用的定理证明工具是Isabelle/HOL。交互式定理证明需要人的参与，由人来创建和引导整个定理的证明。然而，这种方法的好处是不受限于特定的属性或者有穷的状态空间，而不像静态分析和模型检验那样。
本文所论证的是最强意义上的功能正确性。本文采取了一种精炼证明策略，能够确保高层抽象和系统底层的一致性，从而确保了Hoare逻辑在抽象层的属性在底层依然适用。
Figure 2中显示的是用于seL4验证的规约层次。
最顶层的是抽象规约层。该层是对系统的完整的主要的行为进行了规约，包含了足够的细节来体现系统的外在特性，比如系统如何调用二进制的参数以及系统调用的结果。然而，
在这一层次中并没有具体到这些特性都是如何实现的。
接下来的一层是执行规约层。这一层次的规约由Haskell的原型产生。本层包含了所有的数据结构的描述和实现细节。
最底层的是seL4的详细的C代码的实现层。这里要求C代码必须有明确的语义。本文所依赖的项目的一大贡献就是产生了大量的精确的C语言的语义。
验证永远不可能时完备的，因此，在证明之前需要进行适当的假设。本文只限于C代码的实现。
4.总结
本文形式化的验证了seL4操作系统内核，证明了完整的、严格的、形式化的验证一个通用操作系统内核是完全可以实现的。该内核是一个目前可用的内核，可以运行在ARM6或者X86硬件平台上。
5.参考文献
[1] G. Klein, J. Andronick, K. Elphinstone, G. Heiser, D. Cock, P. Derrin, D. Elkaduwe, K. Engelhardt, R. Kolanski, M. Norrish, T. Sewell, H. Tuch, S. Winwood. seL4: Formal Verification of an OS Kernel. CACM 53(6), pages 107-115, ACM 2010.
[2] E. Alkassar, M. Hillebrand, D. Leinenbach,N. Schirmer, A. Starostin, and A. Tsyban. Balancing the load | leveraging a semantics stack forsystems verication. JAR, 42
[3] E. Alkassar, N. Schirmer, and A. Starostin. Formal pervasive verication of a paging mechanism. In C. R. Ramakrishnan and J. Rehof, editors, Tools and Alg. for the Construction and Analysis of Systems(TACAS), volume 4963 of LNCS, pages 109
[4] J. Alves-Foss, P. W. Oman, C. Taylor, and S. Harrison.The MILS architecture for high-assurance embedded systems. Int. J. Emb. Syst., 2:239
[5] M. Archer, E. Leonard, and M. Pradella. Analyzing security-enhanced Linux policy specications. In POLICY '03: Proc. 4th IEEE Int. WS on Policies for Distributed Systems and Networks, pages 158
[6] T. Ball and S. K. Rajamani. SLIC: A specication language for interface checking. Technical
Report MSR-TR-2001-21, Microsoft Research, 2001.
[7] B. N. Bershad, S. Savage, P. Pardyak, E. G. Sirer,M. E. Fiuczynski, D. Becker, C. Chambers, and S. Eggers. Extensibility, safety and performance in the SPIN operating system. In 15th SOSP, Dec1995.
形式化验证：从混成系统到CPS
卜 磊 南京大学 形式化验证：从混成系统到CPS 关键词：形式化验证 混成系统 CPS 混成系统是一种嵌入在物理环境下的实时系统，一般由离散组件和连续组件连接组成，组件之间的行为由计算模型控制。经典混成系统一般分为离散层和连续层，其构成体现了计算机科学和控制理论的交叉。在连续层，通过系统变量对时间的微分方程来描述系统的实际控制操作模型以及系统中参数的演变规律。而在离散层，则通过状态机、佩特里网等高抽象层次模型来描述系统的逻辑控制转换过程。在两层之间通过一定的接口和规则将连续层的信号与离散层的控制模式进行关联和转换。 大多数复杂实时控制系统，都包含连续变化的物理层与离散变化的决策控制层之间的交互过 程，因此混成系统在工业控制和国防等领域大量存在，特别是安全系统，如交通运输、航空航天、医疗卫生、工业控制等。随着在人们生活中的应用越来越广，重要性越来越高，人们对相应系统的质量特别是可信性的需求快速提升，系统失效所带来的灾难也越来越大。在交通运输方面，车 载导航系统的小小失误就可能造成交通事故，而飞机导航系统的失误则可能导致机毁人亡。在国防领域，对软件系统的错误已经进入零容忍度阶段。因此，如何对混成系统进行有效的可信性保 障成为一个亟待解决的问题。 一般而言，测试、仿真[2,3] 等技术是研究和保障软件质量的主要方法。这些方法主要以运行系统为发现问题的主要手段。由于人力无法穷尽地遍历系统所有可能的运行输入和场景，也就不足以保证检测的完备性，这可能会给系统后期运行留下安全隐患。因此，在对系统错误零容忍的安全攸关的系统领域，采用可 证明系统模型正确性的形式化验证理论和技术[4,5]来对系统模型进行安全性验证就显得极为重要，这也成为了相关领域近期的 主要关注点。 混成系统形式化验证 形式化方法 形式化方法(formal method) 混成系统 实时嵌入式系统，特别是复杂的实时控制系统，广泛存在着这样一类子系统：它们行为中的离散化逻辑控制与连续性的时间行为相互依赖，相互影响，彼此互为依存，息息相关。以列车控制系统为例，典型的列车控制系统一般存在多种不同的控制模式以应对当前的车况、路况以及各种突发事件，而系统中的重要参数如列车速度、当前位置、与前车距离等都会随着时间连续发生变化。列车在运行中为了满足特定的时间约束或者调整当前参数的取值而调整列车控制模式。在不同的列车控制模式下，列车中重要参数的变化规律完全不同，对各种事件的响应时间也会有所区别。在类似的这种系统中，逻辑控制与时间行为并不是孤立的两个部分，而是交错地有机结合在一起，构成了一种非常复杂的系统。这种复杂实时系统因其离散控制与实时连续行为混杂叠加的特性，一般被称为混成系统(hybrid system)[1]。
2012学期上学期《软件形式化方法》期末考试试题
学习中心 姓名学号 西安电子科技大学网络教育 2012学年上学期 《软件形式化方法》期末考试试题 （综合大作业） 考试说明： 1．大作业于2012年06月09日下发，2012年06月23日交回。 2．试题必须独立完成，如发现抄袭、雷同均按零分计。 3．试题须手写完成，卷面字迹工整，不能提交打印稿。 一填空题（每空2分，合计30分） 1. 现代软件工程的软件定义包括、和。 2. 软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重的问题，其产生的原因主要包括：、、、；其本质特征是软件的和。 3. 模式是Z语言规格中一个重要的元素，模式是由、和 组成。 4. 形式化方法研究如何把（具有清晰数学基础的）严格性（描述形式、技术和过程等）融入软件开发的各个阶段；包括形式化规格、和三种活动，在软件开发的形式化规格中包含的三种规格为、和。 二有限状态机（10分） 对于图中所示有限状态机的状态转移图，给出其关系矩阵和状态转移表。
三Petri网（10分） 对图中所示Petri网进行化简。 四进程代数（10分） （1）计算进程PHONE的迹 PHONE = ring → answer → hungup→ STOP （2）给出迹投影结果
软件形式化方法-模拟题-3
学习中心_________ 姓名_____________ 学号 西安电子科技大学网络教育学院 模拟试题三 《软件形式化方法》期末考试试题 （120分钟） 题号一二三四五六七总分 题分 得分 一、填空题。（20分） 1. 软件危机是指在计算机软件的过程中所遇到的一系列严重的问题，应对软件危机的方式分为两种方法：和。对于软件开发组织和管理的规范化方法中，主要研究、和三个要素。 2. 形式化方法研究如何把（具有清晰数学基础的）（描述形式、技术和过程等）融入软件开发的各个阶段；包括、形式化验证和程序精化三种活动。形式化验证主要技术包含和；程序精化是将与相结合，研究从抽象的推演出具体的面向计算机的。 3. 模式是Z语言规格中一个重要的元素，模式是由、和 组成。 4. Larch方法是软件系统规格的一种；Larch方法的程序规格包括和与目标语言相关的两个部分。 二、利用有限状态机描述“AB协议”。（15分） AB协议包含发送端和接收端两个实体。发送端协议实体从发送方用户获取一个报文，将序号寄存器值赋给报文，然后向接收端协议实体发出报文，发送方发出报文之后启动超时时钟，等待认可报文。如果在给定的时间内未收到认可报文，则重发报文；如果收到认可报文，其序号与发出报文序号相同，则发送端实体从发送方用户获取下个报文。接收端协议实体在收到报文之后，如果报文无错误，则想发送端实体发送认可报文，然后将报文递交给接收方用户；如果接收的报文有错误或者序号不正确，则丢失报文。假定所用通道不会中断；报文重复n次后最终能够被接收；认可报文只要发出就能正确收到；报文不会损坏；序号寄存器初始化为0 。 三、构造下图所示Petri网的覆盖树。（10分） 四、利用CSP对“生产者-消费者”系统进行规格。（10分） 五、逻辑演算证明。（15分） （1）?(Q∨R) ∧(P?Q)├?P （2）(P?(Q?S)) ∧ (?R∨P) ∧Q├ R→S （3）($x)P(x)?("x)(P(x)úQ(x)?R(x)), ($x)P(x), ($x)Q(x)├ R(a)ùR(c) 六、如图中所示的Kripke结构，利用标号算法对公式进行模型检验。（15） （1）E((p ∧r) ?p) （2）A(p?q) = ?E(?(p?q))
基于Hoare逻辑的密码软件形式化验证系统
基于Hoare 逻辑的密码软件形式化验证系统 郝耀辉郝耀辉，，郭渊博郭渊博，，罗 婷，燕菊维 (解放军信息工程大学电子技术学院，郑州 450004) 摘 要：在Hoare 逻辑理论和ACSL 语法规范的基础上，设计一种针对密码软件的形式化验证系统，由程序规范、验证推理规则、可靠性策略、验证推理等模块组成。以OpenSSL 中RC4算法的软件实现为例，对其功能正确性、保险性和信息流安全性进行验证，结果表明，该系统具有较高的自动化水平，可在一定程度上降低形式化验证方法的复杂度。 关键词关键词：：Hoare 逻辑；密码软件；形式化验证；程序规范；RC4算法 Formal Verification System of Cryptographic Software Based on Hoare Logic HAO Yao-hui, GUO Yuan-bo, LUO Ting, YAN Ju-wei (Institute of Electronic Technology, PLA Information Engineering University, Zhengzhou 450004, China) 【Abstract 】Based on Hoare logic and ANSI/ISO C Specification Language(ACSL) specification, this paper presents a formal verification system for cryptographic software, which is composed of program specification, inference rules, reliability strategy and verification module. It takes the software realization of RC4 algorithm in OpenSSL as an example, the functional correctness, safety properties and information flow security are tested and verified. Results show that this system can reduce the complexity of formal verification method and has a high level of automation. 【Key words 】Hoare logic; cryptographic software; formal verification; program specification; RC4 algorithm DOI: 10.3969/j.issn.1000-3428.2012.03.041 计 算 机 工 程 Computer Engineering 第38卷 第3期 V ol.38 No.3 2012年2月 February 2012 ·安全技术安全技术·· 文章编号文章编号：：1000—3428(2012)03—0121—03 文献标识码文献标识码：：A 中图分类号中图分类号：：TP319 1 概述 密码模块是保障安全系统中信息机密性与完整性的重要 部分，在许多安全系统中，密码模块主要是由密码算法的软 件实现构成，即密码软件部分。这就要求密码软件在向系统 提供安全服务的同时，其自身的安全性也应得到保证。 对此美国国家标准技术局(NIST)和加拿大通信安全局 (CSE)提出CMVP(Cryptographic Module Validation Program) 计划，规定了对安全软件的验证准则DTR [1](Derived Test Requirements)。但CMVP 计划主要依赖验证者的经验，完全 依靠手工完成，存在出错率较高、验证周期长、效率低等缺 点，其时效性和完备性已满足不了实际应用的需求。为此， 本文基于Hoare 逻辑理论，提出一种密码软件的形式化验证 系统。 2 相关知识 本文主要基于Hoare 逻辑原理，依据ACSL(ANSI/ISOC Specification Language)语法规范，对待验证的密码软件添加满足其需要验证的关键特性的前置、后置条件，再用所设计的验证系统对其进行验证。 2.1 Hoare 逻辑 Hoare 逻辑[2]是广泛应用的对命令式语言程序进行推理验证的逻辑系统，其基本思想是在代码段与调用者之间构建一种合同似的规格说明(contracts)，用于描述一段代码执行前后计算机状态的改变情况，由一个前置条件和一个后置条件构成，表示形式为：{Pre}P{Post}，称为Hoare 三元组或断言。其中，Pre 是前置条件，又称初始断言，描述代码段执行前程序状态必须满足的条件，即输入值必须具有的性质；Post 是后置条件，又称终结断言，描述在代码段正确运行后程序 状态所需要满足的条件，即输出值应该具有的性质。 2.2 ACSL 语言 ACSL [3]是一种以注释形式加在程序代码中，专门用于描述程序性质的形式化语言。该语言主要以函数合约(function contract)的形式存在，即要求对任一函数f ，需明确描述清楚函数f 开始时(输入)参数值的要求和结束时(输出)返回值应具有的性质。 其涵义是：若调用函数f 前，前置条件成立，则函数f 执行完后，后置条件也必须成立。其实质和Hoare 三元组表示的内容等同。 2.3 密码软件的关键特性 通过分析密码软件的特性，对保障密码软件安全的至关重要属性进行归纳总结，主要将其归为功能正确性、保险性、信息流安全性3类属性[4]，下面对其进行说明。 2.3.1 功能正确性 主要保证密码软件中程序的执行符合相应的设计规范， 简单的说就是保证程序执行的输入、输出行为和设计规范相 匹配。本系统将其用于验证密码软件输出值是否符合项目输 入值和输出值之间的关系。 2.3.2 保险性 主要指密码软件运行时不引起危险、灾难的能力，本文系统中主要将其用于验证密码软件在开发过程中是否存在缓 基金项目基金项目：：国家“863”计划基金资助项目“基于规范的容忍入侵中 间件关键技术与平台”(2007AA01Z405)；河南省科技创新杰出青年 计划基金资助项目(104100510025) 作者简介作者简介：：郝耀辉(1978－)，女，讲师、硕士，主研方向：信息安全， 密码学，数据库技术；郭渊博，副教授、博士；罗 婷，硕士研究 生；燕菊维，助教、硕士 收稿日期收稿日期：：2011-05-17 E-mail ：hao_yaohui@https://www.360docs.net/doc/9e538144.html,
软件工程中的形式化方法研究论文
软件工程中的形式化方法研究论文 早期软件系统规模较小,20世纪60年代之前,对软件系统的开发一直通过“手工”方式,具有个人化及技艺化的开发特点60年代中期,计算机的容量和速度有了显著提升,软件系统规模越来越大,软件开发生产率不再能满足现状,软件危机开始爆发60年代后期,针对“软件危机”提出两类解决办法:一是将工程化应用于软件的开发过程,即“软件工程”的出现和发展;二是建立严格的理论基础,采用形式化方法来指导软件开发过程经过近半个世纪的探索和应用,形式化方法这一领域已经取得了大量的研究成果 1形式化方法 1.1形式化方法 软件工程中的形式化方法就是通过严格的符号系统和数学模型来描述和验证一个目标软件系统的行为和特性,包括需求规格、设计和实现等形式化方法所使用的是严格的数学语言,其语法和语义都是无二义的、精确的 1.2主要研究内容 形式化方法的研究主要集中在形式规约(FormalSpecification)和建立在形式规约基础上的形式验证(FormalVerification)两个方 面形式规约是指通过具有精确语义的形式语言对程序功能进行描述 描述结果将作为程序设计和验证的重要依据形式验证是对现有的程 序系统进行验证,检查其是否符合规约的要求传统的验证方式是通过实验对系统进行查错,包括模拟(simulation)和测试(testing)
1.3形式化方法的分类 根据描述方式,可将形式化方法归为两类: (1)模型描述的形式化方法通过构造一个数学模型来直接描述系统或程序 (2)性质描述的形式化方法通过对目标软件系统中不同性质的描述来间接描述系统或程序根据表达能力,可将形式化方法大概分为五类[Barroca*1992]: (1)模型方法——对系统状态和改变系统状态的动作直接给出抽象定义,并进行显式描述该方法的缺陷是不能显式地表示并发 (2)代数方法——通过定义不同操作的关系,隐式地描述操作与模型方法相同,代数方法也不能显式地表示并发 (3)进程代数方法——通过一个显式模型来描述并发过程将并发性归结为非确定性,通过交错语义(interleavingsemantics)来表示系统行为如:CCS,CSP,ACP等 (4)逻辑方法——通过描述程序状态规范和时间状态规范的逻辑方法来描述系统特性,如:CTL,LTL (5)网络模型方法——通过独立描述网络中的每一个节点,显式地给出系统的并发模型如:Petri网 2软件方法学 2.1软件危机 60年代后期,软件系统的规模逐步增大,程序实现地复杂度也越来越高,可靠性问题成为越来越多人关注的焦点由于软件开发生产率
形式化方法--程序的正确性验证-14
第十四讲形式化方法--程序的正确性验证 一、概述 计算机的程序是一种静态的对象，但它所描述的问题（问题的解）却是一个动态的对象。所谓的程序设计就是用程序设计语言中的语句改变程序中数据对象的状态，构造所描述问题的动态行为。这是不自然的，程序所描述的动态行为也无法直接用程序本身的静态结构进行正确性证明。 形式化规约（formal specification）是需求阶段的形式化说明，是用户需求的严格描述，其一般形式用Hoare逻辑描述[1]如下： ├{Φ}P{Ψ} <1> 其中Φ和Ψ分别表示初始和结束断言条件，其含义是：“假如初始状态d I满足条件Φ，那么程序结束并且终结状态d f必须满足Ψ”。 设D＝D1×……×D n为程序P的状态空间，其中，D j(j=1,……,n)表示程序中数据对象的值域。显然，由Φ和Ψ断言条件所确定的合法初始和结束状态的集合是D的一个子集。 执行函数E：Φ×P→Ψ定义如下： 无定义对合法的初始状态d i，程序P不结束 E（P,d I）= 终结状态d f对合法的初始状态d i，程序P结束 程序的正确性即为： ├{Φ}P{Ψ} iff <2> ?d i(├Φ(d i)→(├程序P结束 and ├Ψ(E(P,d i)))) 总地来讲，验证一个程序的正确与否有两种办法，一种是程序的测试，另一种是程序的正确性证明。 1．程序的测试与程序的验证 对给定的一个合法的初始状态d i，当程序执行结束时其终结状态为d f，那么，Φ(d i)和Ψ(d f)都应该被满足。这一点可用下式表示： {d i}P{d f} <3> 所谓程序的测试就是验证测试用例{d i}P{d f}，即验证程序对d i的执行结果是否为d f。由于合理的初始状态是无限的，因此，对程序验证来讲，测试不是一个完备的方法。测试被认为是一种尽量发现错误，但并不能保证程序中没有错误[2]的方法。对大数应用来讲，它是可满足的；但对有些应用来讲，测试是一种不能满足的验证方法，例如：航空、航天等领域的软件系统。 显然，对要求绝对正确的软件，测试是一种不能采用的方法。无论白盒测试还是黑盒测试都是在无限集合{(d i,d f)|?d i,?d f, d i和d f满足{d i}P{d f}中选择有限的一些(d i,d f)对进行验证，而各种测试方法只是选择(d i,d f)的策略不同而已。 因此，验证程序是否完全正确要寻求另外的解决途径。那就是程序的正确性验证。 2．形式语义与程序的正确性验证 程序的正确性验证应该具有严密的推量过程，以保证程序每步执行结果都是希望的结果，而与程序执行的某个初始状态无关。程序的正确性证明现有三种方式：操作语义、指称
软件需求的形式化转换模型
第３３卷砌厶３．拿第５期 Ｎｏ．５ 计算机工程 ＣｏｍｐｕｔｅｒＥｎｇｉｎｅｅｒｉｎｇ ２００７年３月 Ｍａｒｃｈ２∞７ ?软件技术与数据库?文章■号ｔ１０００—３４２８（２００７）０５－－－００７３－－０３文■标识码。Ａ中田分类号：］］］ｒ３１１软件需求的形式化转换模型 侯膏珍，蔡小娟，簟恒啊 （上海交通大学计算机科学与工程系，上海２００２４０） ■要：需求规范错误是软件设计错误的一大类。该文提出了一个软件需求的形式化转换模型，用来将软件需求分析直接、自动地转换为形式化描述，为需求验证提供帮助，避免软件在需求规范上可能产生的错误。 关ｔ嗣：软件需求；形式化转换；软件可靠性 Ｄｉｇｅｓｔｉｏｎ－ｂａｓｅｄＳｏｆｔｗａｒｅＦｏｒｍａｌＴｒａｎｓｆｏｒｍａｔｉｏｎ Ｍｏｄｅｌ ＨＯＵＬｉｚｈｅｎ，ＣＡＩＸｉａｏｊｕａｎ，ＺＯＵＨｅｎｇｍｉｎｇ （ＤｅｐａｒｔｍｅｎｔｏｆＣｏｍｐｕｔｅｒＳｃｉｅｎｃｅａｎｄＥｎｇｉｎｅｅｒｉｎｇ，ＳｈａｎｇｈａｉＪｉａｏｔｏｎｇＵｎｉｖｅｒｓｉｔｙ，Ｓｈａｎｇｈａｉ２００２４０） ［Ａｂｓｔｒａｃｔ］Ｒｅｑｕｉｒｅｍｅｎｔｓｐｅｃｉｆｉｃａｔｉｏｎｆａｕｌｔｉｓｏｎｅｋｉｎｄｏｆｓｏｆｔｗａｒｅｄｅｓｉｇｎｆａｕｌｔｓ．Ｔｈｉｓｐａｐｅｒｐｒｅｓｅｎｔｓａｄｉｇｅｓｔｉｏｎ—ｂａｓｅｄｓｏｆｔｗａｒｅｆｏｒｍａｌｔｒａｎｓｆｏｒｍａｔｉｏｎｍｏｄｅｌｔｈａｔｅｌｉｍｉｎａｔｅｓｔｈｅｗｅａｋｌｉｎｋｅｘｉｓｔｉｎｇｉｎｔｏｄａｙ’Ｓｓｏｆｔｗａｒｅｆｏｒｍａｌｍｅｔｈｏｄａｐｐｒｏａｃｈ，ａｎｄａｕｔｏｍａｔｉｃａｌｌｙｔｒａｎｓｆｏｒｍｎａｔｕｒａｌｌａｎｇｕａｇｅ—ｂａｓｅｄｒｅｑｕｉｒｅｍｅｎｔｉｎｔｏ ｆｏｒｍａｌｒｅｐｒｅｓｅｎｔａｔｉｏｎ． ［ＫｅｙｗｏｒｄｓｌＳｏｆｔｗａｒｅｒｅｑｕｉｒｅｍｅｎｔ；Ｆｏｒｍａｌｔｒａｎｓｆｏｒｍａｔｉｏｎ；Ｓｏｆｔｗａｒｅｒｅｌｉａｂｉｌｉｔｙ 在当今信息社会，软件故障造成的各种损失触目惊心。轻则丧财损物，重则直接对人的生命造成威胁。因此，构建可靠软件系统一直是国内外学术机构和信息工业界的一个非常突出和重要的研究课题。 目前高可靠软件系统的研究涵盖在软件工程的领域内，主要研究如何在软件的设计、开发、和实现过程中保持软件的可靠性以达到预先规定的可靠性标准¨’２ｊ。软件之所以存在着这样那样的不可靠性，根本原因是软件在很大程度上作为一门艺术而不是科学被学习和研究，即软件本身的设计因人不同而不同（即程序的构建方式、分拆和编码不同，而不是软件所要完成的功能不同）。 在具体表现上，软件设计的错误可以分为４个方面，即需求规范错误、运行环境错误、模块衔接错误和代码编写错误。本文针对上述４个方面中的一个进行研究，提出了一个软件需求的形式化转换¨。１模型，将软件需求分析直接、自动地转换为形式化描述，从而为需求验证提供帮助，消除软件在需求规范上可能产生的错误。 人们从自然界中食物消化过程中得到了一些启示。食物需要经过一系列步骤才能转化为被人体吸收的营养物质。类似地，软件需求需要经过一系列步骤转化为机器可识别的语言。通过研究和比较这两种过程（消化过程和需求转化过程），抽象出一种形式化转换模型。该模型不仅能提高软件需求转换的可靠性，同时能减轻系统设计人员的工作。 ｌ软件需求的形式化模墼 首先看一下食物消化的过程№Ｊ。食物转化为营养物质，包括以下几个步骤：首先，食物在口腔中被咀嚼，成为较小的食物颗粒。然后，这些较小的食物颗粒被送到胃器官并与胃中的胃酸发生化学反应成为更为细小的食物颗粒。这些小颗粒被送入肠道，由肠道中的微生物（在一系列反应规则下）将它们转化为营养物质。这就完成了一次消化过程。 软件需求的转化与之类似。由自然语言描述的软件需求要被转化为机器可识别的形式，类比于消化过程中胃和肠道，软件形式化转换模型也分为两部分：咀嚼编译器和消化编译器。咀嚼编译器将用自然语言表述的软件需求转化为需求颗粒（半形式化描述）；而消化编译器则进一步把需求颗粒转化为形式化表述。 这种两阶段方式使得整个转换过程容易控制。特别是，咀嚼编译器的工作是将软件需求划分为更小的颗粒，并且将发现的任何问题反馈给用户以便修改。咀嚼编译器产生的任何软件需求小颗粒由消化编译器转化为完全的形式化表述。任何没有正确转换的部分都被退回给用户以供修改。图１描述了这个模型。 圈１软件■求形式化转换过程模型 需求形式化转换过程划分为３个状态：用自然语言表述软件需求的非形式化状态；用伪规则表示的半形式化状态；用形式化语言表述软件需求的形式化状态。软件需求转换过程从初始的非形式化状态开始，以最后的形式化状态终结。显而易见整个转换过程可以用一个带有概率转移矩阵的有限作者骱：侯丽珍（１９８３－－），女，硕士生，主研方向：软件可靠性及数据恢复技术；蔡小娟，博士生；邹恒明，博士 收藕日期：２００６—０３—２８Ｅ－ｍａｉｌ：ｈｌｚ＠ｓｊｔｕ．ｅｄｕ．ｃａ —－７３— 万方数据
形式化验证笔记
形式化验证笔记 2.2 形式化方法简介 形式化方法是一类基于数学的用于精确化规范说明、开发和验证软件和硬件 系统的多种方法的总称[28]。对软件和硬件设计使用形式化方法是为了通过利用适当的数学分析方法，来保证设计的正确性、可靠性和健壮性。形式化方法一般可以分为形式化规范说明(Formal Specification)和形式化验证(Formal Verification)两大类。其中形式化验证又可分为定理证明(Theorem Proving)、模型检测(Model Checking)和自动测试用例生成(Automated Test Case Generation)三类。其中定理证明也称演绎验证(Deductive Verification)。本文中采用的形式化验证方法属于定理证明的范畴。 下面简要介绍一下这三种形式化验证技术: , 模型检测:模型检测是一种通过对目标系统建立一个有限的模型，并在模型发生改变时，检测某系统属性(如安全性和活性)在该模型中是否保持的技术。从本质上讲，模型检测技术就是穷尽地对状态空间搜索，并通过模型的有限性来保证该搜索过程一定会终止。最初模型检测应用在硬件和协议验证领域，大为成功，后来在软件系统的验证上也得到了广泛应用。 , 定理证明:定理证明是一种用某种数学逻辑公式来表达系统及其属性的技术，该数学逻辑公式被定义为一个形式化系统，包含一系列系统公理、已证明的定理及其推论，定理证明的本质就是基于该形式化系统，找到某属性的一个证明的过程。定理证明通常被应用于对软硬件系统重要属性的机械化验证。与模型检测的不同是，定理证明一般是需要人辅助来交互地完成证明的，而模型检测可以达到完全的自动化。由于使用了结构归纳(Structural Induction)等技术，定理
概率论的形式化验证
简介： 软硬件系统通常存在一些随机或不可预测的因素。由于这些随机组件,建立在任何情况下系统的正确性通常特别昂贵，工程的方法是使用概率分析来分析这些带有随机性和不确定性但又不可避免的元件的系统。 传统上，计算机仿真技术被用来执行概率分析。然而,他们给不出精确的结果,并且由于其巨大的计算机处理时间要求而不能处理大规模问题。为克服仿真技术的精度问题，一种解决方案是用高阶逻辑定理验证进行概率分析。 高阶逻辑是一个用精确语义进行推理的系统，它具有足够的表达力以至于能够规范几乎所有经典的数学理论。 对于要形式化的随机变量和任何类型的系统属性（包括概率属性和统计属性）,只要他们能在一个封闭的数学形式中表达，就可以利用高阶逻辑对其行为进行精确建模。 进行基于定理证明的概率分析最重要的标准是能够形式化基础数学理论——测度理论、概率论和勒贝格积分。 最近几年，三个基本理论大部分已在高阶逻辑中形式化。但是前人的工作均有局限性，例如,已形式化的主要测度理论不允许定义在任意拓扑空间中的随机变量的操作；概率论主要不允许我们使用随机变量之和作为随机变量本身。 本文提出一种广义的测度理论、概率理论和勒贝格积分的形式化,以利用他们的全部潜力去形式化概率分析系统。用布莱尔代数的广义形式化扩展测度理论。 证明可测的实值函数的重要性质，使用它们来定义实值随机变量并证明其属性。我们也形式化了独立随机变量的概念并验证了独立随机变量的关键属性。此外,我们证明了勒贝格积分的重要属性用它来定义随机变量的统计特性（期望和方差等）。这些都是目前不存在的。 概率论形式化一些可能应用包括验证安全协议和通信系统 Nedzusiak and Bialas在HOL中形式化了一些测度和概率理论，奠定了概率论分析在HOL中的早期基础。 Hurd构造了概率空间的定义和函数，发展了测度理论在HOL中的形式化。甚至连期望方差的基本概念都没有。 基于Hurd 的工作，Richter在Isabelle/HOL中形式化了测度理论。Richter定义的Borel集是间隔产生的，本文提出的Borel 代数是在开集上产生的，更具广泛性，能被应用到任意度量空间（复数，Rn）(不只是实数空间)。 Coble推广了Hurd的测度理论的形式化，基于此形式化了Lebesgue积分理论。但是他只证明了对于简单正函数的Lebesgue积分性质。 Hasan在上述前人的工作上来验证一些常用的离散或连续随机变量的概率属性和统计属性。展示了概率分析的形式化的实用性继承了缺陷 Lester在PVS中形式化了测度理论和积分理论，但是没有证明Lebesgue积分的性质和收敛定理。
计算机系统形式化验证中的模型检测方法综述论文.doc
面临的挑战和未来发展方向等问题。 2 模型检测及相关技术 模型检测方法最初由Clarke，Emerson等人于1981年提出，因其自动化高效等特点，在过去的几十年里被广泛用于实时系统、概率系统和量子等多个领域。模型检测基本要素有系统模型和系统需满足的属性，其中属性被描述成时态逻辑公式Φ。检测系统模型是否满足时态逻辑公式Φ，如果满足则返回“是”，不满足则返回“否”及其错误路径或反例。时态逻辑主要有线性时态逻辑LTL(Linear TemporalLogic)和计算树逻辑CTL(Computation Tree Logic)。 2.1 线性时态逻辑 对一个系统进行检测，重要的是对系统状态正确性要求的形式化，其中一个基本维度是时间，同时需要知道检验结果与时间维度的关系。使用线性时态逻辑(LTL)来描述系统，可以使得系统更容易被理解，证明过程更加直截了当。LTL公式是一种线性时态逻辑。它在表示授权约束时，定义了无限的未来和过去，这样扩展了常用语义，并且保证了证明中判定的结果在各个时间点中都是成立的。LTL公式用逻辑连接符和时态算子表达系统运行时状态之间的关系。LTL的逻辑连接符包括：∧(与)，∨(或)，—|(非)，→(逻辑包含)，←→(逻辑对等)。时态算子包括：G(Globally)，U(Until)，F(Future)，X(neXt-time)。LTL模型检测验证系统状态转换模型是否满足属性，使用可满足性判定，即为检测系统模型M 中是否存在从某个状态出发的并满足LTL公式—|Φ的路径，如果所有路径都满足LTL公式Φ则不存在有路
径满足—|Φ。使用LTL公式也有一定的局限性，LTL公式只能包括全称量词，对于混用了全称和存在量词的性质，一般无法用这种方法进行模型检测。 2.2 计算树逻辑 计算树即为通过将迁移系统M 某一状态作为根，将M 用树形结构展开表示出来，CTL使用路径量词(包括：A(All)，E(Exist))和时态算子(包括F，G，X，U)对计算树属性进行形式化的描述，表示出系统的状态变化以及状态的分枝情况。LTL的时间定义是与路径相关的，每个时刻只有唯一的一个后继状态。LTL可用于有重点的选择感兴趣的路径分析，并且LTL可以表达公平概念而CTL不能。但是对于一些复杂属性，如每个计算总是可能返回到初始状态，LTL将无法描述，但是CTL可以。CTL的时间定义是与状态相关的，每个状态都有多个可能的后继状态，从一个给定的状态量化分离出路径，能够断言行为的存在。CTL可以用路径量词E，而LTL不可以;CTL公式使用路径量词A时与LTL公式表达内容可以相同。LTL和CTL各有优势，Emerson等人提出扩展的时间逻辑CTL，提供了一种统一的框架，包含了LTL和CTL，但是可满足性判定代价较高。 2.3 模型检测工具 模型检测因其自动化、高效等特点得到广泛应用，各类模型检测工具也层出不穷。以下是几类典型的模型检测工具。SPIN 是1980年美国贝尔实验室开发的模型检测工具，主要关心系统进程间的交互问题。它以promela为建模语言，以LTL为系统属性的逻辑描述语言，支持on-the-fly技术，可以根据用户的需要
四川大学软件系统形式化验证(双语)Software System Model Checking教学大纲
College of Software Engineering Undergraduate Course Syllabus Course ID 311031020 Course Name Software System Model Checking Course Attribute □Compulsory ■Selective Course Language ■English □Chinese Credit Hour 2 Period 32 Semester □First Fall □First Spring □Second Fall □Second Spring ■Third Fall □Third Spring □Fourth Fall □Fourth Spring Instructors Song Xiaoyu Description Today, software systems are widely used in applications where failure is unacceptable. Because of the success of the Internet and embedded systems in automobiles, airplanes, and other safety critical systems, we are likely to become even more dependent on the proper functioning of computing devices in the future. Due to this rapid growth in technology, it will become more important to develop methods that increase our confidence in the correctness of such systems. Traditional verification techniques use simulators with handcrafted or random test vectors to validate the design. Unfortunately, generating test vectors is very labor-intensive. The overall complexity of the designed systems implies that simulation cannot remain the sole means of design verification, and one must look at alternative methods to complement simulation. Recent years have brought about the development of powerful formal verification tools for verifying of software systems. By now, the information technology industry has realized the impact and importance of such tools in their own design and implementation processes. The objective of the course is to introduce the participants to the practical formal verification techniques for hardware/software systems that are beginning to penetrate industrial applications. Topics to be covered include: system modeling, formal logics for system verification (Boolean & first-order logic, higher-order logic, temporal logic), formal specifications, CTL model checking, BDDs, applications of theorem proving systems, and SA T solvers. Exercises are provided in the class. Prerequisites Software and Hardware Systems, Discrete Mathematics. Any senior or graduate student in ECE and CS is welcome to take this course. T extbook E. Clark, O. Grumberg, D. Peled, "Model Checking", MIT Press, 2000. Resource Lecture notes. Grading Assignments, attendance rate (40%) and final exam (60%) T opics Introduction to verification technology. Understand the basic notions of correctness Introduction to formal logics. Understand the basic notions for logics, proofs, specifications. System modeling. Understand the importance of system modeling and specification. Temporal logics. Understand the basic notions of temporal logics. Temporal Logic and Modeling Checking. Understand the extension of CTL, CTL*, etc. Modeling Checking with fixpoint computation. Boolean representations. Find a canonical Boolean representation, etc. Symbolic verification based on BDD and SA T. Symbolic Simulation, BMC Theorem proving systems. L TL model checking, Buchi automata, Omega- automata, etc.
形式化与UML结合的建模方法及其应用
软件设计开发本栏目责任编辑：谢媛媛Computer Knowledge and Technology 电脑知识与技术第5卷第19期(2009年7月)形式化与UML 结合的建模方法及其应用 舒良春，肖美华 （南昌大学计算中心，江西南昌330031） 摘要：首先阐述了形式化方法与可视化方法的优缺点，并在此基础上提出软件体系结构形式化与可视化UML 互补的建模方法，主要探讨UML 和Z 结合的建模过程，并用一个系统开发实例进行展示。 关键词：UML ；Z ；形式化方法；软件体系结构建模 中图分类号：TP311文献标识码：A 文章编号：1009-3044(2009)19-5167-03 Combination of Formalization and UML Modeling Method and its Application SHU Liang-chun,XIAO Mei-hua (Computing Center,Nanchang University,Nanchang 330031,China) Abstract:First of all,express the advantages and disadvantages of the formalization and visualization methods,then based on this,bring for -word the software architecture method ,focused on the modeling process of the combination of UML and Z ,and finally use an example to display. Key words:UML;Z;formalization methods;software architecture modeling 在目前通用的软件开发方法中，其描述通常还是非形式化的方法和工具。然而这种非形式化的方法并不能很好地描述不同组成系统之间的一些特性，已经难以适应软件体系结构研究的进一步发展。因此，在软件体系结构的研究过程中必须要有能显示描述、有独立性的形式化研究工具。形式化方法作为一种严格以数学为基础的方法，能够清晰、精确、抽象、简明地规范和验证软件系统及其性质，帮助发现其它方法不容易发现的系统描述的不一致，不明确或不完整，有助于增加软件开发人员对系统的理解，因而形式化方法能够极大地提高软件的安全性和可靠性。 UML 作为一种通用的对象建模语言，经过了十几年的不断使用、修改、发展和完善，现在逐渐趋于成熟，已成为在软件工业中占支配地位的建模语言，并在许多领域的软件开发中得到应用。但UML 对软件体系结构建模时，缺少分析体系结构所需的准确语义，多视角建模视图之间也存在不一致性，这使得对模型难以进行一致性检查和正确性分析，进而限制了它的有效性。并且。这些非形式化特征使开发者无法从中看出设计的优劣，不利于对系统优劣的度量，不能帮助开发人员评估和改进。 因此，UML 结合形式化的建模方法是解决UML 非形式化缺陷的重要途径之一，并将对软件系统的开发具有重大的研究价值。本文将在对前人关于软件体系结构的形式化方法分析研究的基础上，结合可视化的UML 技术，构造一种新的软件体系结构建模方法。1软件体系结构建模方法概述 形式化描述和可视化描述是目前主要的两类软件体系结构描述方法。其中，形式化描述以体系结构描述语言ADL 为代表，可视化描述以统一建模语言UML 为代表。[1] 1）形式化描述软件体系结构 软件工程中的形式化方法就是依靠数学模型和计算来描述和验证一个目标软件系统的行为和特性，包括需求规格、设计和实现等，其最根本的一点就是建立在严格的数学基础上。使用形式化方法可以帮助开发者获得对其所描述的系统的深刻而正确的理解，发现并及时更正设计中的错误和缺陷。软件开发中的形式化方法主要是形式化规范说明语言，目前广泛应用的一些形式语言，如Z 、VDM ，B 、CSP 、Temporal Logic 、ITL 、Petri 图等，这些形式化方法在功能上各有侧重，可以互补。 z 语言是由英国Oxford 大学程序研究组PRG 的Jean Raymond Abrial 、Bernard Sufrin 等人设计的一种基于一阶谓词逻辑和集合论的形式规格说明语言，它采用了严格的数学理论，可以产生简明、精确、无歧义且可证明的规格说明[2]。z 语言是一种功能很强的形式规格说明语言，可以保证其书写的规格说明文档的正确性，同时还能保证有很好的可读性和可理解性。Z 语言是迄今为止应用最为广泛的形式化语言之一，软件企业在软件开发，特别是大型软件的开发中经常采用z 语言进行需求分析，以产生形式化、精确的需求规格说明。本论文实例分析中的××省电力公司EHR 人力资源系统是一个大型的人力资源管理系统，因而将采用Z 语言这样一个最为适宜的形式化方法。 2）可视化描述软件体系结构 UML 是一种将软件开发过程中出现的各种模型用可视化图形来描述的语言，它融合了多种面向对象开发方法的优点，采用统一的图形和符号从多个视角描述软件系统的各种抽象模型，获得了国际标准化组织的认可，并被国际软件界广泛接纳。但是随着软件规模和复杂性不断增大，UML 的不足就逐渐暴露出来了。这是由于复杂系统的建模往往需要严格的语义分析，而UML 却缺乏准确的语义，这使得对软件体系结构的可构造性建模能力较弱，缺乏形式化语义，对体系结构的描述只能到达非形式化的层次，不利于系统的求精和验证。 收稿日期：2009-04-09 基金项目：2008年江西省研究生创新专项资金省教育厅资助项目-网络协议安全性分析及支撑工具研究（YC08A032） ISSN 1009-3044Computer Knowledge and Technology 电脑知识与技术Vol.5,No.19,July 2009,pp.5167-5169E-mail:xsjl@https://www.360docs.net/doc/9e538144.html, https://www.360docs.net/doc/9e538144.html, Tel:+86-551-569096356909645167