形式化验证操作系统

形式化验证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. TechnicalReport 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.。