形式化验证操作系统
- 格式:pdf
- 大小:175.85 KB
- 文档页数:4
形式化验证操作系统在当今数字化的时代,操作系统作为计算机系统的核心,其稳定性、安全性和可靠性至关重要。
为了确保操作系统能够正确无误地运行,满足各种复杂的需求,形式化验证这一技术逐渐崭露头角。
那么,什么是形式化验证呢?简单来说,形式化验证就是使用严格的数学方法和逻辑推理,来证明一个系统(在这里就是操作系统)是否满足特定的性质和要求。
这可不是像我们平常测试软件那样,通过运行一些案例看看会不会出错。
形式化验证是从根本上、理论上证明系统的正确性。
想象一下,操作系统就像是一个巨大的、复杂的机器,里面有成千上万的零部件在协同工作。
每个零部件都有自己的功能和职责,它们之间的交互和协作必须精确无误,否则整个机器就可能会出现故障。
传统的测试方法可能会漏掉一些隐藏很深的问题,而形式化验证则试图把这个巨大的机器完全拆解,从每一个螺丝钉、每一个齿轮的角度去检查,确保它们的设计和工作方式都是正确的。
形式化验证操作系统的过程可以说是一项极其艰巨的任务。
首先,需要对操作系统的各种功能和行为进行精确的数学建模。
这就要求我们对操作系统的内部结构、工作原理有着非常深入的理解。
比如说,进程调度、内存管理、文件系统等这些核心模块,都要被转化为数学公式和逻辑表达式。
这可不是一件容易的事情,因为操作系统的复杂性超乎想象。
一旦完成了建模,接下来就是运用各种形式化验证的工具和技术来进行推理和证明。
这些工具通常基于复杂的数学理论和算法,能够自动地检查模型是否满足我们设定的性质和要求。
如果在验证过程中发现了问题,那就需要回过头去重新审视模型,找出错误的根源,并进行修正。
形式化验证的好处是显而易见的。
它可以帮助我们发现那些在传统测试中难以发现的微妙错误和潜在的漏洞。
比如说,一些边界情况、并发情况下的竞争条件等等。
通过在设计阶段就发现并解决这些问题,可以大大提高操作系统的质量和可靠性,减少后期出现故障和安全漏洞的风险。
然而,形式化验证也并非一帆风顺。
认识形式化验证 软件开发中⼀般使⽤“测试”来找bug,这种⽅法只能找到bug,不能证明程序没有bug。
形式化验证是⽤逻辑来验证程序的可靠性,就是把⼀段程序⽤逻辑的⽅法证明⼀遍,证明它能得到预期的结果,没有bug。
⼀般这类研究主要应⽤于昂贵的航天器材的操作系统、危险的医疗设备的程序之中。
因为航天器材、医疗设备牵扯到⼈的⽣命,如果操作系统出现错误,那么很危险,⼜不能⽤测试⼀遍⼀遍的测,所以⽤形式化验证来做。
⽐如美国航天局NASA就会雇佣⼤批形式化验证的专家来验证他们操作系统的正确性。
学习这个⽅向,最好有⽐较好的逻辑知识(数理逻辑、拉姆达验算),最好⽐较了解程序(⽐如操作系统的设计、编译器的设计等)。
这个⽅向是⽐较犀利的研究⽅向,但不⼤容易出论⽂,需要长时间积累才能发⼀篇好论⽂。
这个⽅向只是科研⽅向,不适合找⼯作,如果你读完硕⼠打算找⼯作⽽不做研究,这个⽅向不适合。
因为企业没⼈⽤形式化验证来验证程序。
Formal Verification(形式验证) 在计算机硬件(特别是集成电路)和软件系统的设计过程中,形式验证的含义是根据某个或某些形式规范或属性,使⽤数学的⽅法证明其正确性或⾮正确性。
形式验证是⼀个系统性的过程,将使⽤数学推理来验证设计意图(指标)在实现(RTL)中是否得以贯彻。
形式验证可以克服所有3种仿真挑战,由于形式验证能够从算法上穷尽检查所有随时间可能变化的输进值。
形式验证形式验证的出现 由于仿真对于超⼤规模设计来说太耗费时间,形式验证就出现了。
当确认设计的功能仿真是正确的以后,设计实现的每⼀个步骤的结果都可以与上个步骤的结果做形式⽐较,也就是等价检查,如果⼀致就说明设计合理,不必进⾏仿真了。
形式验证主要是进⾏逻辑形式和功能的⼀致性⽐较,是靠⼯具⾃⼰来完成,⽆需开发测试向量。
⽽且由于实现的每个步骤之间逻辑结构变化都不是很⼤,所有逻辑的形式⽐较会⾮常快。
这⽐仿真的时间要少很多。
⼀般要做形式验证的步骤有:RTL和RTL。
卜 磊南京大学形式化验证:从混成系统到CPS关键词:形式化验证 混成系统 CPS混成系统是一种嵌入在物理环境下的实时系统,一般由离散组件和连续组件连接组成,组件之间的行为由计算模型控制。
经典混成系统一般分为离散层和连续层,其构成体现了计算机科学和控制理论的交叉。
在连续层,通过系统变量对时间的微分方程来描述系统的实际控制操作模型以及系统中参数的演变规律。
而在离散层,则通过状态机、佩特里网等高抽象层次模型来描述系统的逻辑控制转换过程。
在两层之间通过一定的接口和规则将连续层的信号与离散层的控制模式进行关联和转换。
大多数复杂实时控制系统,都包含连续变化的物理层与离散变化的决策控制层之间的交互过程,因此混成系统在工业控制和国防等领域大量存在,特别是安全系统,如交通运输、航空航天、医疗卫生、工业控制等。
随着在人们生活中的应用越来越广,重要性越来越高,人们对相应系统的质量特别是可信性的需求快速提升,系统失效所带来的灾难也越来越大。
在交通运输方面,车载导航系统的小小失误就可能造成交通事故,而飞机导航系统的失误则可能导致机毁人亡。
在国防领域,对软件系统的错误已经进入零容忍度阶段。
因此,如何对混成系统进行有效的可信性保障成为一个亟待解决的问题。
一般而言,测试、仿真[2,3]等技术是研究和保障软件质量的主要方法。
这些方法主要以运行系统为发现问题的主要手段。
由于人力无法穷尽地遍历系统所有可能的运行输入和场景,也就不足以保证检测的完备性,这可能会给系统后期运行留下安全隐患。
因此,在对系统错误零容忍的安全攸关的系统领域,采用可证明系统模型正确性的形式化验证理论和技术[4,5]来对系统模型进行安全性验证就显得极为重要,这也成为了相关领域近期的主要关注点。
混成系统形式化验证形式化方法形式化方法(formal method)混成系统实时嵌入式系统,特别是复杂的实时控制系统,广泛存在着这样一类子系统:它们行为中的离散化逻辑控制与连续性的时间行为相互依赖,相互影响,彼此互为依存,息息相关。
形式化验证在软件系统安全性分析中的应用研究随着现代社会科技的不断发展, 软件系统的应用范围越来越广, 也越来越重要。
然而软件系统中存在的安全问题也不断增加,这是造成财产损失,政治事件等重大问题的原因之一。
软件系统的安全性保护变得越来越重要, 为了保障软件系统的安全性,需要采取有效的安全分析方法。
其中,形式化验证在软件系统安全性分析中的应用引起了人们的广泛关注。
一、形式化验证的概念形式化验证,是利用形式系统的形式化理论,对被验证的对象进行严格的形式化证明或推理的过程,通过科学的方法证明一个特定的模型是否符合其描述的特定规范, 并评估其正确性的方法。
这种方法可以明确地指出潜在的错误和缺陷, 可以有效地提高系统可靠性和安全性。
二、形式化验证在软件系统中的应用形式化验证在软件系统中的应用,主要是针对可配置软件,实时系统,分布式系统,网络安全等一系列复杂系统中软件复杂度高、交互设计模糊不清等问题。
形式化验证在软件系统中具有多种优点,包括精准性高、可重用性强、再现性好、自动化测试能力强等。
三、形式化验证的优点1. 精准性高: 形式化验证通过机器执行的方式可以对软件系统进行全面而细致的分析,可以准确地找出软件系统的缺陷和错误,提高软件的安全性和可靠性。
2. 可重用性强: 形式化验证所生成的模型及证明可以多次重复使用,可以避免重复设计和测试的过程,大大提高了工作效率。
3. 再现性好: 在形式化验证中使用的数学方法具有良好的可重复性,可以通过执行机器这个部分来得到非常一致的结果,这也是形式化验证成为可靠系统的优点之一。
4. 自动化测试能力强: 形式化验证可以使用计算机执行大部分的工作,可以在比手工测试更短的时间内自动化检查更多的属性,并提供更好的准确度和可预测性。
四、形式化验证在软件系统安全性分析中的实际应用形式化验证在软件系统安全性分析中的应用方案比较广泛,其中比较具有代表性的有以下几种:1. 从源代码到最终系统: 通过检查源代码可以找出其中静态缺陷,但静态分析的结果可能会忽略一些与实现相关的微小错误。
形式化验证操作系统第一点:形式化验证操作系统的必要性和挑战形式化验证是一种利用数学方法来验证软件系统正确性的技术。
在操作系统领域,形式化验证可以帮助我们确保操作系统的稳定性和安全性,避免系统出现崩溃、漏洞等问题。
随着信息技术的快速发展,操作系统在人们生活中的地位越来越重要,其安全性和稳定性也变得越来越受到关注。
因此,对操作系统进行形式化验证成为了计算机科学领域的一个重要研究方向。
然而,形式化验证操作系统面临着诸多挑战。
首先,操作系统的复杂性非常高,其中包含了大量的模块和相互依赖的关系。
这使得对操作系统进行形式化验证的难度大大增加。
其次,形式化验证需要对操作系统的所有可能执行路径进行覆盖,以确保系统的正确性。
然而,操作系统的执行路径数量非常庞大,人工很难对其进行完全分析和验证。
此外,操作系统的运行环境非常复杂,很难通过形式化方法来描述和验证系统与环境之间的交互。
第二点:形式化验证操作系统的方法和工具尽管形式化验证操作系统面临诸多挑战,但研究人员还是提出了一些方法和工具来帮助我们进行形式化验证。
其中,最为常见的方法是使用定理证明和模型检查技术。
定理证明是一种利用数学推理来证明系统性质的方法。
在操作系统领域,定理证明可以用来验证操作系统的正确性和安全性。
通过定理证明,我们可以证明操作系统中的某个性质在所有可能的情况下都成立。
然而,定理证明的方法往往需要深入了解操作系统的内部实现和数学理论,对研究人员的专业素质要求较高。
模型检查是一种利用自动化工具来验证系统性质的方法。
在操作系统领域,模型检查可以用来验证操作系统的正确性和安全性。
通过模型检查,我们可以自动地检查操作系统模型中的所有可能执行路径,以确保系统的正确性。
模型检查的方法较为简单,易于上手,但可能无法覆盖到操作系统的所有可能性。
综上所述,形式化验证操作系统是一种非常重要的方法,可以帮助我们确保操作系统的稳定性和安全性。
尽管形式化验证操作系统面临诸多挑战,但通过定理证明和模型检查等方法和工具,我们仍然可以对操作系统进行较为有效的验证。
控制电路的形式化验证大家好,今天来聊聊“控制电路的形式化验证”这个话题,说实话,听起来有点高大上、深奥得让人直冒冷汗,对吧?但其实呢,放轻松,这不过是一个让我们在设计电路时,确保它能够“乖乖”地按预期运行的工具罢了。
大家都知道,电路设计就像给自己的“电子宠物”编程,你希望它乖巧、听话,不会突然掉链子、乱跑一气。
那问题来了,怎么确保它不会发生意外呢?形式化验证就是那个“电子宠物培训师”,帮你查漏补缺,防止意外发生。
我得先给大家科普一下,什么叫做“形式化验证”吧。
这个“形式化”可不是让电路穿上西装、打上领带,做个高大上的样子。
而是通过一些严格的数学方法、逻辑推理来证明电路设计在理论上是没问题的。
通俗点说,它就是用一种“严谨、死磕”的态度,来保证你的电路就算在最糟糕的情况下也能正常工作。
试想一下,如果你家的电路设计不经过形式化验证,万一有个小小的bug,它可能就成了“定时炸弹”,一不小心就会烧掉一堆元器件,甚至连你的家电都可能因此受到牵连,结果就是—“这锅可不小啊!”然后呢,咱们再聊聊它为什么重要。
电路设计的复杂程度就像人类的思维一样,永远不会是线性的,可能会涉及到大量的状态切换、复杂的逻辑判断。
你知道的,电流和电压这种东西就像是“高压电”,一旦出错,后果不堪设想。
有些小小的疏忽,最后都可能导致大问题。
所以呢,形式化验证就像是“验尸官”,它能提前“推理”出电路可能出现的问题,绝对不是简单的“走过场”。
你设计的每一个模块、每一个细节都能通过它的严格审查,给你“打个保票”,确保万无一失。
形式化验证可不是那种拿来敷衍了事的工具,它可是有真本事的。
我们设计电路时,常常会碰到这种情况:一个小小的bug,自己检查半天也找不出来,就像是掉进了无底洞,怎么也找不到出口。
但形式化验证,它不是那种“看了半天也没结果”的空口说白话,而是能通过系统性的算法和数学模型,从根本上找出你设计上的每一个漏洞。
这就像一个超级侦探,能够在你设计上每个环节“细细筛查”,不放过一丝一毫的错误。
计算机系统形式化验证中的模型检测方法综述形式化方法是用数学和规律的方法来描述和验证系统设计是否满意需求。
它将系统属性和系统行为定义在抽象层次上,以形式化的标准语言去描述系统。
形式化的描述语言有多种,如一阶规律,Z 语言,时序规律等。
采纳形式化方法可以有效提高系统的平安性、全都性和正确性,关心分析冗杂系统并且及早觉察错误。
形式化验证是保证系统正确性的重要方法,主要包括以数学、规律推理为根底的演绎验证(deductive verification)和以穷举状态为根底的模型检测(model checking)。
演绎验证是基于人工数学来证明系统模型的正确性。
它利用规律公式来描述系统,通过定理或证明规章来证明系统的某些性质。
演绎验证既可以处理有限状态系统,又可以解决无限状态问题。
但是演绎验证的过程一般为定理证明器帮助,人工参加,无法做到完全自动化,推导过程冗杂,工作量大,效率低,不能适用于大型的冗杂系统,因此适用范围较窄。
常见的演绎验证工具有HOL,ACL2,PVS和TLV等。
模型检测主要应用于验证并发的状态转换系统,通过遍历系统的状态空间,对有限状态系统进展全自动验证,快速高效地验证出系统是否满意其设计期望。
下面将主要介绍模型检测方法的进展历史和讨论现状,以及当前面临的挑战和将来进展方向等问题。
2 模型检测及相关技术模型检测方法最初由Clarke,Emerson等人于1981年提出,因其自动化高效等特点,在过去的几十年里被广泛用于实时系统、概率系统和量子等多个领域。
模型检测根本要素有系统模型和系统需满意的属性,其中属性被描述成时态规律公式Φ。
检测系统模型是否满意时态规律公式Φ,假设满意那么返回“是”,不满意那么返回“否”及其错误路径或反例。
时态规律主要有线性时态规律LTL(Linear TemporalLogic)和计算树规律CTL(Computation Tree Logic)。
2.1 线性时态规律对一个系统进展检测,重要的是对系统状态正确性要求的形式化,其中一个根本维度是时间,同时需要知道检验结果与时间维度的关系。
形式化验证操作系统形式化验证操作系统是指使用数学和逻辑推理的方法来验证操作系统的正确性和可信性。
这种验证方法通过形式化规范和精确的证明来检查操作系统设计和实现中可能存在的错误和安全漏洞。
下面将介绍形式化验证操作系统的背景、方法和应用。
背景:操作系统是一个复杂的软件系统,负责管理计算机的硬件资源和提供服务。
操作系统的正确性至关重要,因为操作系统中的错误和漏洞可能导致系统崩溃、数据丢失、安全漏洞等严重后果。
传统的测试方法对于操作系统的验证来说是不够的,因为测试只能覆盖有限的场景,而操作系统的功能和交互非常复杂。
形式化验证通过形式化规范和证明来检查操作系统的设计和实现是否满足预期的性质,能够提供更严谨和全面的验证。
方法:1.型检查:使用类型系统对操作系统的源代码进行静态检查,识别类型错误和不合理的操作。
2.模型检查:将操作系统的设计和实现抽象为一个有限状态机或其他形式的模型,然后使用模型检查工具来自动验证这个模型是否满足预期的性质。
3.定理证明:将操作系统的设计和实现表示为一组数学公理和规则,然后使用定理证明工具来证明这些公理和规则,以及预期的性质是否成立。
4.符号执行:通过对操作系统的源代码进行符号执行,自动生成可能的执行路径,并使用约束求解器来判断这些路径是否满足预期的性质。
5.静态分析:对操作系统的源代码进行静态分析,通过检查代码中的约束、不变量和错误模式来发现潜在的错误和漏洞。
应用:1. seL4操作系统:seL4是一个基于L4微内核的开源操作系统,使用形式化验证的方法对其进行了验证。
seL4的正确性和安全性已经由严格的数学证明证明。
2. CertiKOS:CertiKOS是一个基于Coq证明助手的操作系统,能够提供严格和可信的正确性证明。
CertiKOS被广泛应用于关键系统的开发和安全性验证。
3. Linux核心验证项目:Linux核心验证项目使用Coq证明助手对Linux核心模块的功能和安全性进行了验证,并发布了一系列的验证结果和工具。
1.安全性与操作系统之间的关系是怎样的?2.从操作系统安全的角度如何理解计算机恶意代码、病毒、特洛伊木马之间的关系?恶意代码指的所有感染计算机并且造成破坏的程序,病毒是恶意代码的一种,可以复制感染计算机程序造成破坏。
而特洛伊木马是一种载体,它伪装成合法的程序,在执行的时候才把隐藏在其中的恶意代码释放,如病毒、蠕虫等。
3.从操作系统面临的安全威胁看,密码服务与操作系统安全功能之间的关系如何?密码服务虽然主要依赖于应用层的密钥管理功能,但是如果操作系统无法保护数据文件,无法有效的保护密钥,那么数据加密的作用将大大降低,所以操作系统安全是密码服务的基石。
4.简述操作系统安全和信息系统安全之间的关系?操作系统的安全性在计算机信息系统的整体安全性中具有至关重要的作用,没有操作系统提供的安全性,信息系统的安全性是没有基础的。
5.简述安全操作系统研究的主要发展过程。
6.Linux自由软件的广泛流行为什么会对我国安全操作系统的研究与开发具有积极的推进作用?1.安全操作系统的安全功能与安全保证之间有怎样的关系?安全功能主要说明操作系统所实现的安全策略和安全机制符合评价准则哪一级的功能要求。
而安全保证则是通过一定的方法保证操作系统所提供的安全功能确实达到了确定的功能要求。
2.从操作系统安全的角度如何区分可信软件与不可信软件?软件保证能安全运行,并且后来系统的安全也依赖于软件的无错操作。
3.在操作系统中哪些实体即可以是主体又可以为客体?请举例说明。
在操作系统中,进程作为用户的客体,同是又是其访问对象的主题。
4.如何从安全策略、安全模型和系统安全功能设计之间的关系上,来验证安全内核的安全?安全策略是指有关管理、保护和发布敏感信息的法律、规定和实施细则。
安全模型则是对安全策略所表达的安全需求的简单、抽象和无歧义的描述,它为安全策略和安全策略实现机制的关联提供了一种框架。
JP指出要开发安全系统首先应该建立系统的安全模型。
=5.为什么要将可信的管理人员列入可信计算基的范畴?由于系统管理员的误操作或恶意操作也会引起系统的安全性问题,因此他们也被看做TCB的一部分。
不为人知的中国航天SpaceOS操作系统未来将民用说起微软的Windows;苹果的Mac OS以及谷歌的Android;相信大家都不会陌生;它们都是操作系统;即对计算机的各种资源进行管理的软件;是计算机能够运行的灵魂;美国的一些航天器上用的就是VxWorks操作系统..但是;如果问起我国航天器上的计算机用的是什么操作系统;也许很少有人知道..事实上;中国航天科技集团公司五院从2001年就开始研发星载计算机特有的操作系统——SpaceOS;并在2006年首飞成功..此次的嫦娥三号探月任务控制计算机使用的是经过升级和改进后的第二代星载计算机操作系统SpaceOS2..该系统首次亮相应用;就吸引了众多关注的目光..中国航天要有自己的操作系统尽管与普通家用的操作系统设计原理相似;但“上天”的操作系统为了适应恶劣太空环境;对安全性、可靠性等要求要苛刻许多..地面使用的计算机死机了可以重启;坏了还可以换新的;但飞行器上的计算机开机了通常就不会再关闭或重启..在轨运行时间较长的卫星寿命可达十几年;这也就意味着计算机程序要同步运行十几年不出现问题..更重要的是;对于航天这样的事关国家安全的关键领域;“拿来主义”是很危险的..而要研发自己的操作系统;相关核心技术国外严密封锁;想要借用也没有可能..在星载计算机操作系统投入使用以前;中国的卫星通常都采用程序控制的方式来完成指令..这种“傻瓜”式的运行模式非常简单;但也非常机械;它要求技术人员在地面设计好卫星要进行的每一个动作;严格按照时序编写程序..形象地说;就是如果设定卫星的任务为“吃饭—喝水—睡觉”;卫星上天之后只能按照这个顺序重复动作;想要先喝水后吃饭是做不到的..由于卫星的运行轨道相对封闭和确定;程序控制虽然机械繁琐;也能够满足任务要求..但随着我国在轨任务越来越复杂;对计算机软件管理提出了越来越高的要求..研发中国自己的星载计算机操作系统势在必行..没有借鉴;就从零开始慢慢摸索..独立自主创新;成为了摆在研发团队面前唯一道路..两代SpaceOS的华丽蜕变2006年;SpaceOS1成功在轨运行..那时的操作系统功能简单;只做到了多种资源的管理和任务调度;却没有任务间的通信和动态内存管理等更为复杂的功能..3年以后;嫦娥三号立项;巡视器要实现月面行走..相比卫星轨道;月球是一个开放的空间;环境恶劣、不确定因素多、控制复杂..这种任务对航天器智能性和自主性的要求很高;而这恰恰是操作系统的绝佳用武之地..此时功能简单的SpaceOS1已无法满足任务要求;科研人员开始着手进行第二代产品的攻关..经过2年研发;SpaceOS2正式推出;在很多方面都实现了质的飞跃;并成功应用到了嫦娥三号巡视器的中心控制计算机上..在任务调度和内存管理方面;SpaceOS2可以同时管理几十个任务;与原来5个任务相比;提高了一个量级;同时可以做到快速、有序存储..月球车在月面行走时;要一边不停地拍摄月面环境;一边快速保存和处理这些信息..如果此时突然遇到一个坑;操作系统必须在最短的时间内作出判断并反应;否则就有可能掉进坑里..目前;研究人员设计的内存管理方法和调度方法;从功能、效率上来讲;已经可以和国际上最先进的类似产品相媲美..而如果说到最具有我国特色和竞争力的技术;就不得不提到三机容错..一般卫星上会有两台计算机冷备份;一台工作时另一台不工作;如果工作的计算机出现了故障或问题;就立刻切换到另一台..但切换的过程中;不可避免的会有一些因计算机启动等带来的秒级的时间差..为了实现真正的无缝切换;嫦娥三号上第一次实现了三机热备份;即三个计算机同时工作;处理同样的任务;有可能其中一台计算机给出的计算结果是错的;那么三机容错就要发现哪台计算机有错;并最终给出正确的结果..从双机冷备份到三机热备份;看上去似乎只增加了一台计算机;但带来的难度和工作量却是呈指数级增长的..研发人员坦言;那种压力来自于知道应该实现什么目标;但对怎么实现毫无头绪..那时做梦都在思考这些问题;有些难关甚至是在梦里攻克的..未来或可发展为民用目前;这个只有十几个人组成的年轻团队正在进行SpaceOS3的研发工作;第三代产品的技术将更加先进和前沿..例如研制高性能多核计算机;让运算速度和处理能力大幅度提升;还有目前操作系统领域最前沿的技术——形式化验证;即从建模和证明的角度来验证设计领域软硬件的正确性;如果这一技术得以突破;将改变航天目前通过大量测试来验证设计正确性的方法;从根本上确保设计的无差错和高可靠..SpaceOS操作系统能否发展民用当被问及这个问题时;研发人员表示;航天操作系统技术本身是可以转为民用的..但由于航天精品化和个性定制的特点;不够产品化和通用化;距推广成熟的民用产品还有一定距离..目前;SpaceOS操作系统正在考虑航天系统内的推广应用;未来还将逐步拓展到其他领域..也许有一天;我们每个人的手机上;都可以使用到“中国航天”品牌的操作系统了..江雪莹。
形式化验证技术在计算机系统设计中的应用研究计算机系统设计是一门综合性极强的学科,其中各种复杂的算法和各种不同的硬件设计都需要高度精细的控制和设计。
然而,由于实现的复杂性极高,开发者常常需要借助现代技术进行验证,以保证其设计的正确性。
形式化验证作为一种现代的、高效的计算机系统验证工具,由于其对设计进行全面地检查,适合于检测设计缺陷、歧义和未考虑到的条件,因此被广泛使用于计算机系统设计领域。
本文将详细探讨形式化验证在计算机系统设计中的应用与研究,从理论辅助到实现应用的方方面面进行探讨,以期更好地了解该技术现状与未来发展趋势。
1.形式化验证技术的基本原理形式化验证技术在设计阶段主要解决三个问题:1、确定正确的使用与破坏产品的操作和行为;2、在测试用例方面不仅能够通过应用实例化实现测试,更能通过对规范的形式描述以及数学证明来检查、验证正确性;3、在产品应用阶段必须满足其规范,且维护阶段也必须满足规范。
其基本原理是通过形式化检查和数学证明来证明设计的正确性和健壮性,并通过形式化方法对设计进行彻底的测试,以确保设计在各种场景下表现出正确的行为。
形式化验证技术还可以使用可验证性属性来准确地描述系统的预期行为,以及不当行为的特征。
2.形式化验证技术的应用形式化验证技术被广泛应用于计算机系统设计的各个方面中,比如硬件设计、嵌入式系统、软件开发等领域。
这里我们将只讨论硬件设计的方面,包括集成电路、芯片和系统设计等方面。
2.1 硬件设计硬件设计是形式化验证技术重要应用方向之一,其主要包括以下几个方面:(1)生产设备的测试和验证对于生产出的设备,通过硬件测试来检测其功能和性能,但很难检测出由于不正确的设计而造成的错误。
形式化验证技术通过放大测试的效果,可以在不修改硬件设计的情况下,通过验证驱动来检测出硬件中的潜在问题。
(2)按键、开关、电源和驱动器验证按键、开关、电源和驱动器都必须在各种各样的组合和序列操作下正常工作。
内核验证的方法
内核验证的方法是指对操作系统内核进行验证和测试的方法。
内核是操作系统中最核心的部分,负责管理系统的硬件和软件资源,因此内核验证是非常重要的。
内核验证的方法有很多种,以下是一些常见的方法:
1.静态代码分析:这种方法通过检查代码的语法和结构来发现潜在的错误和
漏洞。
工具如Clang Static Analyzer、Cppcheck等可以帮助进行静态代码分析。
2.动态分析:这种方法在内核运行时进行,通过观察内核的行为来发现潜在
的问题。
工具如Valgrind、AddressSanitizer等可以帮助进行动态分析。
3.模糊测试:模糊测试通过向系统提供无效、意外或随机的数据来检测系统
的异常行为。
这种方法可以发现一些其他方法难以发现的问题。
4.符号执行:符号执行是一种形式化的验证方法,它通过使用符号值代替实
际值来检查系统是否满足某些属性。
这种方法可以发现一些其他方法难以发现的问题。
5.覆盖率测试:覆盖率测试通过测量测试用例覆盖的代码比例来评估测试的
质量。
这种方法可以帮助发现未被测试覆盖的代码区域。
总的来说,内核验证的方法是通过各种手段对操作系统内核进行测试和验证,以确保其正确性和安全性。
这些方法包括静态代码分析、动态分析、模糊测试、符号执行和覆盖率测试等。
形式化验证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.。