下载文档原格式
外文出处：Ellekilde, L. -., & Christensen, H. I. (2009). Control of mobile manipulator using the dynamical systems approach. Robotics and Automation, Icra 09, IEEE International Conference on (pp.1370 - 1376). IEEE.机械臂动力学与控制的研究拉斯彼得Ellekilde摘要操作器和移动平台的组合提供了一种可用于广泛应用程序高效灵活的操作系统,特别是在服务性机器人领域。
在机械臂众多挑战中其中之一是确保机器人在潜在的动态环境中安全工作控制系统的设计。
在本文中,我们将介绍移动机械臂用动力学系统方法被控制的使用方法。
该方法是一种二级方法, 是使用竞争动力学对于统筹协调优化移动平台以及较低层次的融合避障和目标捕获行为的方法。
I介绍在过去的几十年里大多数机器人的研究主要关注在移动平台或操作系统，并且在这两个领域取得了许多可喜的成绩。
今天的新挑战之一是将这两个领域组合在一起形成具有高效移动和有能力操作环境的系统。
特别是服务性机器人将会在这一方面系统需求的增加。
大多数西方国家的人口统计数量显示需要照顾的老人在不断增加,尽管将有很少的工作实际的支持他们。
这就需要增强服务业的自动化程度，因此机器人能够在室内动态环境中安全的工作是最基本的。
图、1 一台由赛格威RMP200和轻重量型库卡机器人组成的平台这项工作平台用于如图1所示,是由一个Segway与一家机器人制造商制造的RMP200轻机器人。
其有一个相对较小的轨迹和高机动性能的平台使它适应在室内环境移动。
库卡工业机器人具有较长的长臂和高有效载荷比自身的重量,从而使其适合移动操作。
当控制移动机械臂系统时,有一个选择是是否考虑一个或两个系统的实体。
在参考文献[1]和[2]中是根据雅可比理论将机械手末端和移动平台结合在一起形成一个单一的控制系统。
计算机研究与发展ＩＳＳＮ １０００－１２３９?ＣＮ １１－１７７７?ＴＰＪｏｕｒｎａｌ ｏｆ Ｃｏｍｐｕｔｅｒ Ｒｅｓｅａｒｃｈ ａｎｄ Ｄｅｖｅｌｏｐｍｅｎｔ ４８（８）：１４３８－１４４６，２０１１基于ＶＭＭ层系统调用分析的软件完整性验证李 博 李建欣 胡春明 沃天宇 怀进鹏（北京航空航天大学计算机学院 北京 １００１９１）（ｌｉｂｏ＠ａｃｔ．ｂｕａａ．ｅｄｕ．ｃｎ）Ｓｏｆｔｗａｒｅ Ｉｎｔｅｇｒｉｔｙ Ｖｅｒｉｆｉｃａｔｉｏｎ Ｂａｓｅｄ ｏｎ ＶＭＭ－Ｌｅｖｅｌ Ｓｙｓｔｅｍ Ｃａｌｌ ＡｎａｌｙｓｉｓＴｅｃｈｎｉｑｕｅＬｉ Ｂｏ，Ｌｉ Ｊｉａｎｘｉｎ，Ｈｕ Ｃｈｕｎｍｉｎｇ，Ｗｏ Ｔｉａｎｙｕ，ａｎｄ Ｈｕａｉ Ｊｉｎｐｅｎｇ（Ｓｃｈｏｏｌ ｏｆ Ｃｏｍｐｕｔｅｒ Ｓｃｉｅｎｃｅ ａｎｄ Ｅｎｇｉｎｅｅｒｉｎｇ，Ｂｅｉｈａｎｇ Ｕｎｉｖｅｒｓｉｔｙ，Ｂｅｉｊｉｎｇ１００１９１）Ａｂｓｔｒａｃｔ Ｉｎ ｖｉｒｔｕａｌｉｚｅｄ ｃｌｏｕｄ ｃｏｍｐｕｔｉｎｇ ｐｌａｔｆｏｒｍ，ｔｈｅ ｋｅｙ ｓｅｃｕｒｉｔｙ ｐｒｏｂｌｅｍ ｉｓ ｔｏ ｇｕａｒａｎｔｅｅｔｒｕｓｔｗｏｒｔｈｉｎｅｓｓ ｏｆ ｔｈｅ ｓｏｆｔｗａｒｅｓ ｗｈｉｃｈ ａｒｅ ｒｕｎｎｉｎｇ ｉｎ ｔｈｅ ｐｌａｔｆｏｒｍ．Ｉｎｔｅｇｒｉｔｙ ｍｅａｓｕｒｅｍｅｎｔ ａｎｄｖｅｒｉｆｉｃａｔｉｏｎ ｈａｓ ｂｅｅｎ ｐｒｏｐｏｓｅｄ ａｎｄ ｓｔｕｄｉｅｄ ｂｙ ｍａｎｙ ｒｅｓｅａｒｃｈｅｒｓ ａｓ ａｎ ｅｆｆｅｃｔｉｖｅ ｗａｙ ｔｏ ｖｅｒｉｆｙ ｔｈｅｉｎｔｅｇｒｉｔｙ ｏｆ ｃｏｍｐｕｔｅｒ ｓｙｓｔｅｍｓ．Ｈｏｗｅｖｅｒ，ｅｘｉｓｔｉｎｇ ａｐｐｒｏａｃｈｅｓ ｈａｖｅ ｓｏｍｅ ｌｉｍｉｔａｔｉｏｎｓ ｏｎ ｃｏｍｐａｔｉｂｉｌｉｔｙ，ｓｅｃｕｒｉｔｙ ａｎｄ ｍａｉｎｔａｉｎａｂｉｌｉｔｙ，ａｎｄ ｃａｎｎｏｔ ｂｅ ａｐｐｌｉｅｄ ｉｎｔｏ ｔｈｅ ｃｌｏｕｄ ｃｏｍｐｕｔｉｎｇ ｐｌａｔｆｏｒｍ．Ｉｎ ｔｈｉｓ ｐａｐｅｒ，ｗｅ ｐｒｏｐｏｓｅ ａ ａｐｐｒｏａｃｈ ｎａｍｅｄ ＶＭＧｕａｒｄ，ｗｈｉｃｈ ｌｅｖｅｒａｇｅｓ ＶＭＭ ｔｏ ｅｎａｂｌｅ ｔａｋｅ ｉｎｔｅｇｒｉｔｙ ｍｅａｓｕｒｅｍｅｎｔｏｕｔｓｉｄｅ ｔｈｅ ｏｐｅｒａｔｉｎｇ ｓｙｓｔｅｍ．Ｗｅ ａｄｏｐｔ ＶＭＭ－ｂａｓｅｄ ｓｙｓｔｅｍ ｃａｌｌ ｉｎｔｅｒｃｅｐｔｉｏｎ ｔｅｃｈｎｉｑｕｅ ｔｏ ｄｅｔｅｃｔ ｔｈｅｅｘｅｃｕｔｉｏｎ ｏｆ ｂｉｎａｒｉｅｓ．Ｓｙｓｔｅｍ ｃａｌｌ ｃｏｒｒｅｌａｔｉｏｎ ａｎｄ ｇｕｅｓｔ ＯＳ ｆｉｌｅ ｓｙｓｔｅｍ ｍｅｔａｄａｔａ ｒｅｃｏｎｓｔｒｕｃｔｉｏｎ ａｒｅｐｒｏｐｏｓｅｄ ｔｏ ｖｅｒｉｆｙ ｔｈｅ ｉｎｔｅｇｒｉｔｙ ｏｆ ｓｏｆｔｗａｒｅ ｉｎ ｇｕｅｓｔ ＯＳ．Ｗｅ ｈａｖｅ ｄｅｖｅｌｏｐｅｄ ａ ｐｒｏｔｏｔｙｐｅ ｏｆ ＶＭＧｕａｒｄａｎｄ ｉｍｐｌｅｍｅｎｔｅｄ ｉｔ ｉｎ ｔｗｏ ｍａｉｎｓｔｒｅａｍ ｖｉｒｔｕａｌ ｍａｃｈｉｎｅ ｍｏｎｉｔｏｒｓ，Ｑｅｍｕ ａｎｄ ＫＶＭ，ｒｅｓｐｅｃｔｉｖｅｌｙ．Ｗｅａｌｓｏ ｅｖａｌｕａｔｅ ｔｈｅ ｅｆｆｅｃｔｉｖｅｎｅｓｓ ａｎｄ ｐｅｒｆｏｒｍａｎｃｅ ｏｖｅｒｈｅａｄ ｏｆ ｏｕｒ ａｐｐｒｏａｃｈ ｂｙ ｃｏｍｐｒｅｈｅｎｓｉｖｅｅｘｐｅｒｉｍｅｎｔｓ．Ｔｈｅ ｒｅｓｕｌｔｓ ｓｈｏｗ ｔｈａｔ ＶＭＧｕａｒｄ ａｃｈｉｅｖｅｓ ｅｆｆｅｃｔｉｖｅ ｉｎｔｅｇｒｉｔｙ ｍｅａｓｕｒｅｍｅｎｔ ｗｉｔｈ ｌｅｓｓ ｔｈａｎ１０％ｏｖｅｒｈｅａｄ．Ｋｅｙ ｗｏｒｄｓ ｃｌｏｕｄ ｃｏｍｐｕｔｉｎｇ；ｖｉｒｔｕａｌｉｚａｔｉｏｎ；ｉｎｔｅｇｒｉｔｙ ｖｅｒｉｆｉｃａｔｉｏｎ；ｓｙｓｔｅｍ ｃａｌｌ ａｎａｌｙｓｉｓ；ｓｏｆｔｗａｒｅｌｏａｄｉｎｇ摘 要 在虚拟化云计算平台中，如何保证其上运行软件的可信性是云平台广泛应用的关键．完整性测量与验证技术是保证软件系统可信性的一种主要方法．然而，现有的软件完整性验证系统大多需要修改操作系统内核，很难为大规模虚拟机环境中的众多异构系统提供一致解决方案，且无法抵御内核级恶意攻击．针对当前方法在兼容性、安全性以及可管理性上存在的问题，设计并实现了一种在ＶＭＭ层基于系统调用分析技术来验证软件完整性的方法ＶＭＧｕａｒｄ．它通过截获客户操作系统中的系统调用来识别软件加载，并基于系统调用关联性分析和虚拟机文件系统元数据重构技术来验证客户操作系统中软件的完整性．在Ｑｅｍｕ和ＫＶＭ两种主流虚拟化平台上实现了ＶＭＧｕａｒｄ，并通过实验评测ＶＭＧｕａｒｄ的有效性和性能．实验结果表明，ＶＭＧｕａｒｄ能够有效验证客户操作系统中软件的完整性，且性能开销在１０％以内．关键词 云计算；虚拟化；完整性验证；系统调用分析；软件加载中图法分类号 ＴＰ３０９ 收稿日期：２０１１－０４－０７；修回日期：２０１１－０６－０９ 基金项目：国家自然科学基金项目（９１０１８００４，６０９０３１４９）；国家“九七三”重点基础研究发展计划项目（２０１１ＣＢ３０２６００）；北京航空航天大学科技领航基金项目（ＹＷＦ－１１－０２－０１０） 云计算（ｃｌｏｕｄ ｃｏｍｐｕｔｉｎｇ）等新型网络计算模式通过有效聚合网络、服务器、存储以及服务等资源，以按需使用（ｏｎ－ｄｅｍａｎｄ）模式实现资源的动态分配，为用户提供简单、透明访问方式以及动态获取大规模计算和存储服务的能力．其中，虚拟化云计算平台采用虚拟化技术实现对底层计算、存储和网络资源的封装，并以虚拟机的形式提供给上层用户．而如何保证其上运行软件的可信性成为影响整个云计算平台安全性的关键．完整性测量和验证技术是确保软件可信性的基本方法，该方法通过对比软件测量指纹识别软件是否被篡改，来验证软件系统的完整性．然而传统软件完整验证方法用于云计算平台软件可信性确保方面存在如下问题：１）兼容性问题．传统软件完整性验证方法大多需要修改操作系统内核（如ＩＭＡ［１］），甚至需要修改或重新编译应用程序（如ＰＲＩＭＡ［２］）．而虚拟化云计算平台承载着大量遗留操作系统和软件，无法被修改或重新编译；另一方面，这些方法需要与特定操作系统绑定，无法对多类型操作系统提供统一支持（例如，ＩＭＡ只能用于Ｌｉｎｕｘ操作系统）．因此，针对虚拟化云计算平台所承载的各类型操作系统和软件，需要提供统一的完整性验证方法．２）安全性问题．传统软件完整性验证方法如Ｔｒｉｐｗｉｒｅ［３］，ＩＭＡ［１］等依赖于操作系统内核的完整性，属于一种弱攻击模型假设，无法抵御内核态攻击，例如ＩＭＡ采用Ｌｉｎｕｘ安全内核机制完成完整性验证功能，需要依赖内核保证验证结果的正确性．因此，对于虚拟化云计算平台的完整性验证方法，需要具有抵御内核攻击的能力．３）可管理性问题．虚拟化云计算平台通过虚拟机技术屏蔽了操作系统异构性，提供对大规模虚拟机的集中式统一管理．然而，现有完整性验证技术由于其实现依赖于特定操作系统，很难对其进行集中管理和升级维护．因此，对于虚拟化云计算平台的完整性验证方法，需要提供一种自动化集中式管理机制．针对上述问题，本文提出了一种基于虚拟监控器（ｖｉｒｔｕａｌ ｍａｃｈｉｎｅ ｍｏｎｉｔｏｒ，ＶＭＭ）的软件完整性验证方法ＶＭＧｕａｒｄ，它通过系统调用截获和分析方法对上层操作系统及软件进行完整性验证．然而，在ＶＭＭ层进行软件完整性验证存在一系列技术挑战：第一，在ＶＭＭ层无法直接识别客户操作系统中软件加载行为．当前在ＶＭＭ和客户操作系统内部抽象两者之间存在着语义鸿沟（ｓｅｍａｎｔｉｃ ｇａｐ），当前主要通过虚拟机自省［４］（ＶＭ ｉｎｔｒｏｓｐｅｃｔｉｏｎ）技术在ＶＭＭ层获取虚拟机内部信息，但所能获取信息不完整，从而无法满足软件加载期完整性验证需求．例如虚拟机自省技术通过读取内核数据结构来获得进程列表，但此时软件已经处于运行期，攻击者完全可以通过将进程从内核ｔａｓｋ链表移除方法来隐藏进程，从而逃避检测；Ａｎｔｆａｒｍ［５］通过读取ＣＲ３寄存器来识别活动进程，但获取的信息过于底层，缺乏足够的进程上下文信息，很难追溯到软件的可执行代码，因而无法进行完整性验证．第二，在ＶＭＭ层无法直接获取软件路径．由于软件二进制代码会在软件开始运行后按照按需加载（ｐａｇｅ ｏｎ ｄｅｍａｎｄ）原则动态加载进内存，因此无法在加载期对软件在内存中的镜像进行完整性验证（此时软件还未真正加载入内存），因此需要通过当前上下文信息回溯找到软件二进制代码在文件系统中的位置．第三，在ＶＭＭ层无法直接提取虚拟机内部文件进行测量．即使定位到软件的文件系统路径，也无法直接对软件作测量，因为从虚拟机监控器层的角度，只能看到虚拟机磁盘镜像，无法获取虚拟机内部的文件系统抽象．针对云计算平台软件完整性验证需求及面临的技术挑战，本文主要贡献如下：１）提出了一种基于ＶＭＭ的软件完整性验证方法ＶＭＧｕａｒｄ．该方法在软件加载期执行完整性验证，不仅实现了对软件实体的完整性测量，还能识别并阻止恶意软件实体对系统完整性的破坏．相比传统验证方法的优势体现在：①无需修改客户操作系统，并解决了异构系统兼容性问题；②避免客户操作系统旁路甚至破坏完整性验证机制，解决了ＶＭＧｕａｒｄ的安全性问题；③提供自动、统一的完整性验证方法，在ＶＭＭ层集中管理，便于升级维护，解决云平台软件完整性验证系统的可管理性问题．２）针对主要技术挑战，提出了３项解决方法：基于系统调用截获的软件加载识别、基于系统调用关联分析的可执行程序定位和文件系统可感知的虚拟机内部文件测量．３项技术均在虚拟机监控器层实现，对上层操作系统透明，适用于各种客户操作系统；同时具有更高的安全性，即使客户操作系统内核被攻破也不影响底层安全机制．３）在２种主流虚拟化平台（ＫＶＭ［６］和Ｑｅｍｕ［７］）上实现了ＶＭＧｕａｒｄ原型系统，并使用恶意软件样本９３４１李 博等：基于ＶＭＭ层系统调用分析的软件完整性验证和标准测试程序评估ＶＭＧｕａｒｄ的有效性和性能．实验结果表明ＶＭＧｕａｒｄ在有效对客户操作系统中的运行软件进行完整性验证的同时，仅带来了不超过１０％的运行时开销．１ ＶＭＧｕａｒｄ系统本节给出ＶＭＧｕａｒｄ的总体架构以及关键技术．１．１ 总体架构图１给出了ＶＭＧｕａｒｄ的总体架构．ＶＭＧｕａｒｄ包括２个主要模块：系统调用截获模块和完整性验证模块．其中，系统调用截获模块首先截获客户操作系统中的系统调用事件，从中识别出与可执行程序加载相关的系统调用序列，解析其参数并获得可执行程序在文件系统中的路径，并将路径传给完整性验证模块．完整性验证模块基于接收到的可执行程序路径，结合抽取到的客户文件系统元信息，在虚拟机镜像中读取并测量可执行程序的二进制文件；得到的测量值（通常是Ｈａｓｈ）首先被输出到日志文件，接着与指纹库中的已有指纹比对以验证其完整性，验证结果将为用户提供软件完整性证据．同时，完整性验证模块还可以配置成强安全模式．在该模式下，如果验证结果不匹配，则通过传递错误参数的方式终止当前的系统调用，从而阻止程序的加载运行．Ｆｉｇ．１ Ａｒｃｈｉｔｅｃｔｕｒｅ ｏｆ ＶＭＧｕａｒｄ．图１ ＶＭＧｕａｒｄ总体架构１．２ 基于系统调用截获的软件加载识别１．２．１ 系统调用截获在现代操作系统中，用户程序通过系统调用来访问内核服务．在ｘ８６处理器架构上，当用户程序发起系统调用时，首先会将系统调用参数放入相关寄存器，然后执行中断指令陷入内核．在虚拟化场景下，ＶＭＭ将首先拦截系统调用，具体流程如图２所示．不同虚拟化技术下的系统调用截获技术略有不同．本文实现了二进制翻译和硬件支持虚拟化２种Ｆｉｇ．２ ＶＭＭ－ｌｅｖｅｌ ｓｙｓｔｅｍ ｃａｌｌ ｉｎｔｅｒｃｅｐｔｉｏｎ．图２ ＶＭＭ层系统调用截获平台下的系统调用截获技术．在二进制翻译技术中，虚拟机监控器需要截获上层操作系统执行的敏感指令．因而，在ＶＭＭ运行时，会在执行上层指令前检查所有来自上层操作系统的指令．当检测到敏感指令时，会强制陷入ＶＭＭ层．中断指令（ＩＮＴ）和中断返回指令（ｉＲＥＴ）都是敏感指令，因此可以被ＶＭＭ所截获．针对硬件支持虚拟化平台，我们采用了Ｅｔｈｅｒ［８］中提出的系统调用截获技术．解决问题的关键在于重写系统调用入口指针，使之指向一个非法地址．当系统调用发起时会导致页错误，从而引发ｖｍｅｘｉｔ指令，并发送给ＶＭＭ异常处理模块．我们在该模块中插入完整性验证代码；执行完成后，通过恢复原有的系统调用入口地址来继续正常的执行流程．１．２．２ 软件加载识别在截获系统调用后，ＶＭＧｕａｒｄ通过系统调用类型和参数来识别３种可执行程序的加载．可执行程序的加载过程涉及多个系统调用．以Ｌｉｎｕｘ操作系统中的用户应用程序的加载为例，首先操作系统会创建一个新进程，接下来调用ｅｘｅｃｖｅ系统调用服务例程．该系统调用服务例程会在文件系统中找到该程序的可执行文件，并用该文件中描述的上下文信息替换刚创建进程的上下文．当系统调用完成后，将运行在新的上下文中．在这一过程中，ＶＭＧｕａｒｄ会截获所有系统调用，从相应的ｖＣＰＵ寄存器中读取系统调用号，并检查其是否等于ｅｘｅｃｖｅ的系统调用号；如果相等，则说明截获到ｅｘｅｃｖｅ系统调用（系统调用号唯一标识了一个系统调用），从而识别出用户应用程序的加载．类似地，动态链接库和内核模块的加载也可以通过系统调用号匹配的方式来识别．１．３ 基于系统调用关联分析的可执行程序定位在识别可执行程序加载后，ＶＭＧｕａｒｄ将定位可执行程序的文件系统路径．通过读取客户虚拟机０４４１计算机研究与发展 ２０１１，４８（８）的ｖＣＰＵ上下文以及获取用户堆栈指针可以定位系统调用参数．接着ＶＭＧｕａｒｄ通过这些参数来获取可执行程序路径．获取路径的最佳时机是识别出程序加载的时刻，然而此时的系统调用参数很可能不包含程序的路径信息．例如，ｉｎｉｔ＿ｍｏｄｕｌｅ系统调用标志着内核模块的加载，截获该系统调用得到的参数中不包含内核模块路径，并且由于ＶＭＧｕａｒｄ位于ＶＭＭ层，无法借助任何内核函数和数据结构来获取路径信息．针对这一问题，我们采用“事先记录、事发回溯”的方法．我们注意到在任何可执行程序加载前，首先会通过ｏｐｅｎ系统调用打开．其中，ｏｐｅｎ系统调用的第１个参数就是文件路径．因此，我们首先记录客户操作系统中发生的ｏｐｅｎ系统调用及其参数；当截获到识别可执行程序加载的系统调用时，通过回溯找到打开该程序的ｏｐｅｎ系统调用，并获取路径信息．解决问题的关键在于建立ｏｐｅｎ系统调用和识别程序加载系统调用间的关联关系．首先，ＶＭＧｕａｒｄ需要截获系统调用返回事件，并获得系统调用返回值，因为返回值是２个相互关联的系统调用间的唯一纽带．例如，ｏｐｅｎ系统调用的返回值是文件描述符，该参数将作为ｍｍａｐ系统调用的输入参数．但这里存在一个问题，从ＶＭＭ的角度看，系统调用是并发执行的，也就是说系统调用进入和返回事件是异步的．换句话说，当我们在ＶＭＭ层截获到一个系统调用进入事件，接下来截获到系统调用返回事件，这两者很可能来自于２个不同的系统调用．针对这一问题，我们通过在ＥＩＰ寄存器中存放的当前程序指针来追踪来自同一系统调用的进入和返回事件．当发生系统调用进入时，程序指针（ｉｎｓｔｒｕｃｔｉｏｎ ｐｏｉｎｔｅｒ）会被操作系统内核保存起来；当系统调用返回时，内核会将保存值加载到ＥＩＰ寄存器，从而恢复程序的继续运行．因此，我们通过程序指针来确定系统调用进入和返回事件是否属于同一个系统调用．然而，这一论断在某些极端情况下并不成立．在现代操作系统中，进程具有自身的独立虚拟地址空间，不同进程在运行中的程序指针有可能相同．因此，基于以上方法可能会导致某个进程的系统调用进入事件错误地匹配到另一个进程的系统调用退出事件．针对这一问题，我们使用ＣＲ３寄存器的值来区分不同进程．在ｘ８６平台上，ＣＲ３寄存器中存储着当前运行进程的页目录表的基地址，因而该值唯一地标识了当前进程．至此，我们获得了系统调用的返回值，接下来将通过该返回值来建立系统调用间的关联关系．以Ｌｉｎｕｘ动态链接库加载为例，我们通过ｏｐｅｎ和ｍｍａｐ两个系统调用来获得动态链接库的路径．其中，参数中指定了ｐｒｏｔ＿ｅｘｅｃ的ｍｍａｐ系统调用标志着动态链接库的加载．由图３所示，在客户操作系统中运行着Ａ和Ｂ两个进程，会并发执行系统调用．细线和粗线分别代表了进程Ａ和进程Ｂ的系统调用执行轨迹．进程Ａ首先引发了ｏｐｅｎ系统调用，接着调用ｍｍａｐ来加载动态链接库．为了在截获ｍｍａｐ系统调用时能获得该动态链接库的文件路径，我们首先截获了ｏｐｅｎ系统调用的进入事件，这时以（ＣＲ３，ＩＰ）为ｋｅｙ，以ｐａｔｈ为ｖａｌｕｅ，存入Ｈａｓｈ．接着截获ｏｐｅｎ系统调用的返回事件，此时以当前ｖＣＰＵ上下文中的ＣＲ３和ＩＰ寄存器值为ｋｅｙ从Ｈａｓｈ表中获取相应的Ｐａｔｈ，并生成新的（ｋｅｙ，ｖａｌｕｅ）对（ｋｅｙ（ＣＲ３，ｆｄ），ｖａｌｕｅ（ｐａｔｈ））存入Ｈａｓｈ表．最后，当我们截获到标志着动态链接库加载的ｍｍａｐ系统调用时，以当前ＣＲ３寄存器值和ｆｄ为ｋｅｙ，从Ｈａｓｈ表中获得对应的值，也就是动态链接库的文件路径．Ｆｉｇ．３ Ｐａｔｈ ｉｎｆｅｒｒｉｎｇ ｍｅｔｈｏｄ ｂｙ ｓｙｓｔｅｍ ｃａｌｌ ｃｏｒｒｅｌａｔｉｏｎ．图３ 基于系统调用关联分析的路径获取过程１．４ 文件系统可感知的虚拟机内部文件测量技术ＶＭＧｕａｒｄ获得的可执行程序路径位于客户虚拟机中的文件系统．而ＶＭＭ只能观测到虚拟机磁盘镜像文件，无法获得其内部存储的客户文件系统信息，因此无法直接通过路径读取文件．通常的做法是通过在宿主操作系统挂载（ｍｏｕｎｔ）客户文件系统的方式来访问虚拟机内部文件，但这种方式存在以下问题．首先，可读可写的挂载方式会向虚拟磁盘中写入数据，有可能破坏虚拟磁盘和客户文件系统原有的数据结构，甚至导致虚拟机无法正常运行．其次，１４４１李 博等：基于ＶＭＭ层系统调用分析的软件完整性验证若采用只读挂载，虽然不会影响虚拟机的正常运行，但在运行中的虚拟机客户文件系统的修改无法反映到宿主机上挂载的只读文件系统，因而造成不一致状态．针对以上问题，首先ＶＭＧｕａｒｄ通过分析虚拟磁盘中的文件系统布局在ＶＭＭ层重建客户文件系统的元数据（ｍｅｔａｄａｔａ），使ＶＭＧｕａｒｄ能够感知到客户文件系统的内部状态和数据结构；接着以元数据为索引来读取并测量存储于虚拟机磁盘镜像中的可执行文件．由于不同的文件系统在磁盘上布局不尽相同，因此该方法是文件系统相关的，目前只支持Ｅｘｔ２和Ｅｘｔ３两种．两者在Ｌｉｎｕｘ上使用最为广泛，且互相兼容．需要指出的是，本方法不局限于这２种文件系统，只要掌握文件系统的内部结构，就可以使用本方法来重建元数据信息．具体过程如下：首先，ＶＭＧｕａｒｄ通过读取文件系统超级块（ＳｕｐｅｒＢｌｏｃｋ）信息来获取文件系统参数（如ｂｌｏｃｋｓｉｚｅ等），并初始化“文件系统”数据结构；接着，ＶＭＧｕａｒｄ读取文件系统根目录的ｉｎｏｄｅ信息以建立根目录数据结构，并通过ｉｎｏｄｅ中的数据块信息来初始化根目录的“数据块”数据结构；最后，以根目录为起点，通过解析目录文件内容递归建立整个文件系统目录树和其他数据结构．这一过程在虚拟机运行前执行，建立的元数据结构首先会被持久化到宿主机文件系统．当虚拟机即将运行前加载入内存，不影响虚拟机启动和运行时的性能．在客户文件系统元数据重建好后，ＶＭＧｕａｒｄ根据可执行程序名通过搜索文件系统目录树定位到该文件的数据结构，并通过ｉｎｏｄｅ地址指针定位文件的ｉｎｏｄｅ信息，基于ｉｎｏｄｅ信息读取文件数据，并利用ＳＨＡ１算法对程序文件数据进行完整性测量．测量值将被存储到宿主机文件系统的日志文件．完整性测量过程从虚拟机启动开始，在加载内核代码前，ＶＭＧｕａｒｄ首先验证客户操作系统内核文件ｉｎｉｔｒｄ和ｖｍｌｉｎｕｚ的完整性，如果发现篡改会立即终止客户操作系统的运行以确保内核加载的安全性．验证通过后继续测量３种可执行程序．２ 系统实现我们在Ｑｅｍｕ和ＫＶＭ两种完全虚拟化平台上实现了ＶＭＧｕａｒｄ的原型系统．目前，ＶＭＧｕａｒｄ已实现对Ｌｉｎｕｘ客户操作系统中的软件进行完整性测量和验证，它可以支持ｘ８６架构下的各版本Ｌｉｎｕｘ内核．ＶＭＧｕａｒｄ并不局限于Ｌｉｎｕｘ客户操作系统，它可以被移植到其他使用系统调用功能的操作系统上．表１给出了Ｌｉｎｕｘ操作系统下与用户应用程序（ｕｓｅｒ ａｐｐｌｉｃａｔｉｏｎ）、动态链接库（ｓｈａｒｅｄ ｌｉｂｒａｒｙ）和内核模块（ｋｅｒｎｅｌ ｍｏｄｕｌｅ）的加载相关的系统调用参数．Ｔａｂｌｅ １ Ｌｉｎｕｘ Ｓｙｓｔｅｍ Ｃａｌｌｓ ｔｏ Ｌｏａｄ ａｎｄ Ｅｘｅｃｕｔｅ Ｂｉｎａｒｉｅｓ表１ Ｌｉｎｕｘ操作系统中与软件加载相关的系统调用Ｓｏｆｔｗａｒｅ Ｔｙｐｅ Ｓｙｓｔｅｍ Ｃａｌｌ Ｎａｍｅ Ｓｙｓｔｅｍ Ｃａｌｌ ＮｕｍｂｅｒＵｓｅｒ Ａｐｐｌｉｃａｔｉｏｎ ｅｘｅｃｖｅ １１Ｓｈａｒｅｄ Ｌｉｂｒａｒｙｍｍａｐ（ＰＲＯＴ＿ＥＸＥＣ）９０１９２Ｋｅｒｎｅｌ Ｍｏｄｕｌｅ ｉｎｉｔ＿ｍｏｄｕｌｅ １２８２．１ ＶＭＧｕａｒｄ在Ｑｅｍｕ上的实现我们在Ｑｅｍｕ－０．９．１下实现了ＶＭＧｕａｒｄ－Ｑｅｍｕ原型系统．Ｌｉｎｕｘ ２．４及之前版本采用ＩＮＴ ８０ｈ指令来执行系统调用，而Ｌｉｎｕｘ ２．６及之后版本默认使用ｓｙｓｅｎｔｅｒ指令执行系统调用．ＶＭＧｕａｒｄ－Ｑｅｍｕ采用统一的系统调用截获方式，通过禁用Ｑｅｍｕ虚拟ＣＰＵ中ＣＰＵＩＤ的ＳＥＰ ｂｉｔ，使所有系统调用都通过ＩＮＴ ８０ｈ指令执行．ＶＭＧｕａｒｄ－Ｑｅｍｕ在Ｑｅｍｕ的函数ｄｏ＿ｉｎｔｅｒｒｕｐｔ中插入钩子函数（ｈｏｏｋ）以截获ＩＮＴ ８０ｈ系统调用指令．２．２ ＶＭＧｕａｒｄ在ＫＶＭ上的实现在ＫＶＭ上实现ＶＭＧｕａｒｄ需要ＣＰＵ支持Ｉｎｔｅｌ ＶＴ硬件虚拟化技术．当前，我们在ＫＶＭ－８４下实现了ＶＭＧｕａｒｄ－ＫＶＭ原型系统．为了截获系统调用，ＶＭＧｕａｒｄ－ＫＶＭ首先在客户操作系统的启动阶段保存ＧＵＥＳＴ＿ＳＹＳＥＮＴＥＲ＿ＥＩＰ寄存器的正常值，并写入一个非法地址．当通过ｓｙｓｅｎｔｅｒ指令执行系统调用时，会首先访问ＧＵＥＳＴ＿ＳＹＳＥＮＴＥＲ＿ＥＩＰ指向的地址，由于该地址已被改写为非法地址，因此会抛出页错误（ｐａｇｅ ｆａｕｌｔ）异常，并陷入ＫＶＭ虚拟机监控器中．ＶＭＧｕａｒｄ－ＫＶＭ在ＫＶＭ内核模块中插入异常处理代码捕获该异常，同时执行系统调用识别以及完整性验证等操作．验证完成后，ＶＭＧｕａｒｄ－ＫＶＭ将把ＧＵＥＳＴ＿ＳＹＳＥＮＴＥＲ＿ＥＩＰ寄存器恢复为之前的保存值，从而恢复正常的程序执行流程．３ 实验及结果分析３．１ ＶＭＧｕａｒｄ系统有效性实验我们执行了４组实验来评价ＶＭＧｕａｒｄ的有效２４４１计算机研究与发展 ２０１１，４８（８）性．前３组实验分别用来验证ＶＭＧｕａｒｄ是否能有效识别３种可执行程序的加载并进行完整性验证．１）用户应用程序．我们用ｌｒｋ５，一款Ｌｉｎｕｘ下流行的Ｒｏｏｔｋｉｔ恶意软件，来检验ＶＭＧｕａｒｄ对应用程序完整性测量的有效性．ｌｒｋ５由一组攻击工具集组成，其中ｓｓｈｄ－２．０．１３是一个最新加入的后门程序，它篡改了正常的ｓｓｈｄ程序，用来远程连接被攻击主机并隐藏连接．如图４（ａ）所示，ＶＭＧｕａｒｄ首先发现了该程序的加载，并对其进行了完整性测量，通过与指纹库中已有的指纹进行对比，ＶＭＧｕａｒｄ识别出了该程序的恶意篡改行为．Ｆｉｇ．４ Ｓｃｒｅｅｎｓｈｏｔ ｏｆ ＶＭＧｕａｒｄ ｐｒｏｔｏｔｙｐｅ．图４ ＶＭＧｕａｒｄ原型系统实验截图２）动态链接库．Ｌｉｎｕｘ动态链接库有隐式和显式２种加载方式．我们用Ｌｉｎｕｘ中常用的ｌｓ命令来验证ＶＭＧｕａｒｄ是否能够识别并验证所有在ｌｓ执行过程中隐式加载的动态链接库．如图４（ｂ）所示，ＶＭＧｕａｒｄ共识别出了７个动态链接库的加载，这一结果符合ｌｓ实际调用动态链接库的情况．同时，我们也通过Ｄｌｏｐｅｎ加载动态链接库来验证了ＶＭＧｕａｒｄ对显示加载模式的有效性．３）内核模块．攻击者常利用加载内核模块达到入侵操作系统内核的目的．Ａｄｏｒｅ－ｎｇ是一款著名的内核级恶意软件，我们用它来验证ＶＭＧｕａｒｄ内核模块验证的有效性．为了模拟黑客的攻击行为，我们将Ａｄｏｒｅ－ｎｇ伪装成Ｌｉｎｕｘ ａｃｐｉ驱动中的ｆａｎ内核模块，并调用ｍｏｄｐｒｏｂｅ命令将其加载入内核．图４（ａ）显示的结果表明ＶＭＧｕａｒｄ检测出对ｆａｎ内核模块的恶意篡改．同时我们编写了测试内核模块ｔｅｓｔ．ｋｏ，由于指纹库中没有该模块的软件指纹，因此ｔｅｓｔ．ｋｏ被标记为“未知”软件．由于ＶＭＧｕａｒｄ对内核模块的加载采用强安全模式，因此本实验中ｔｅｓｔ．ｋｏ被拒绝加载．３．２ ＶＭＧｕａｒｄ系统性能实验我们的硬件测试环境为一台配置为Ｉｎｔｅｌ Ｄｕｏ２．４ＧＨｚ ＣＰＵｓ和４ＧＢ内存的ＰＣ．宿主环境运行的操作系统版本为３２ｂ的Ｄｅｂｉａｎ ｌｅｎｎｙ发行版．对于虚拟机客户操作系统，我们分别测试了包括Ｌｉｎｕｘ ２．４和２．６内核在内的多种Ｌｉｎｕｘ发行版．由于篇幅所限，本文仅给出在Ｌｉｎｕｘ ２．６客户操作系统下的测试结果．测试结果数据均是重复实验的平均值．３．２．１ 微基准测试我们采用ｌｍｂｅｎｃｈ作为本次实验的微基准测试集．由于ＶＭＧｕａｒｄ基于系统调用截获和分析技术所实现，为了充分测试ＶＭＧｕａｒｄ的性能开销，我们从ｌｍｂｅｎｃｈ中选择了与系统调用相关基准测试指标．通过分别测试ＶＭＧｕａｒｄ在Ｑｅｍｕ和ＫＶＭ两种实现下的性能指标，并通过与标准Ｑｅｍｕ和ＫＶＭ进行对比来分析ＶＭＧｕａｒｄ所引入的性能开销．表２和表３分别给出了相应的测试结果．Ｔａｂｌｅ ２ Ｍｉｃｒｏｂｅｎｃｈｍａｒｋ Ｒｅｓｕｌｔｓ ｏｆ ＶＭＧｕａｒｄ－Ｑｅｍｕ表２ ＶＭＧｕａｒｄ－Ｑｅｍｕ微基准测试结果μｓＭｉｃｒｏＢｅｎｃｈｍａｒｋｎｕｌｌｏｐｅｎ?ｃｌｏｓｅｒｅａｄ ｗｒｉｔｅｆｏｒｋ＋ｅｘｅｃｂａｓｈ＋ｅｘｅｃＶａｎｉｌｌａ Ｑｅｍｕ ０．８６ ２０．９ ２．３２ １．８４ ２ ８８５ ９ ０８７ＶＭＧｕａｒｄ １．１０ ２２．４ ２．６６ ２．３６ ３ ０６８ １９ ０５５Ｔａｂｌｅ ３ Ｍｉｃｒｏｂｅｎｃｈｍａｒｋ Ｒｅｓｕｌｔｓ ｏｆ ＶＭＧｕａｒｄ－ＫＶＭ表３ ＶＭＧｕａｒｄ－ＫＶＭ微基准测试结果μｓＭｉｃｒｏＢｅｎｃｈｍａｒｋｎｕｌｌｏｐｅｎ?ｃｌｏｓｅｒｅａｄ ｗｒｉｔｅｆｏｒｋ＋ｅｘｅｃｂａｓｈ＋ｅｘｅｃＶａｎｉｌｌａ ＫＶＭ ０．１５ １．７３ ０．２５ ０．２１ ２ ０６５ ５ ３１５ＶＭＧｕａｒｄ ５．８２ １４．４７ ６．１４ ６．０７ ２ ２７７ １１ ３８８ 首先，对比表２和表３中的数据，标准ＫＶＭ下的系统调用处理时间远小于标准Ｑｅｍｕ．这是由于Ｑｅｍｕ需要捕获并模拟所有系统调用指令，而ＫＶＭ在硬件辅助下无需虚拟机监控器的干预，从而避免了频繁切换所带来的性能开销．其次，通过对比表２和表３前２行数据我们发现，对于前４项基准测试指标（ｎｕｌｌ，ｏｐｅｎ，ｒｅａｄ，ｗｒｉｔｅ），ＶＭＧｕａｒｄ－ＫＶＭ相比于ＶＭＧｕａｒｄ－Ｑｅｍｕ引入了更多的性能开销．例如，对于ｏｐｅｎ测试指标，３４４１李 博等：基于ＶＭＭ层系统调用分析的软件完整性验证ＶＭＧｕａｒｄ－Ｑｅｍｕ引入的性能开销为２２．４－２０．９＝１．５μｓ；而ＶＭＧｕａｒｄ－ＫＶＭ引入的性能开销为１４．４７－１．７３＝１２．７４μｓ，远高于ＶＭＧｕａｒｄ－Ｑｅｍｕ的１．５μｓ．这是由于在标准Ｑｅｍｕ中，系统调用指令已经被识别并进行了指令翻译，ＶＭＧｕａｒｄ－Ｑｅｍｕ利用Ｑｅｍｕ已有机制来截获系统调用，因而不会带来较大开销；而在ＶＭＧｕａｒｄ－ＫＶＭ中，需要通过强制引发页错误异常，并由虚拟机监控器捕获的方式来截获系统调用．这一过程中经历了从用户操作系统到ＶＭＭ，以及ＶＭＭ返回用户操作系统内核２次切换，因此开销较大．最后，ＶＭＧｕａｒｄ在ｆｏｒｋ＋ｅｘｅｃ和ｂａｓｈ＋ｅｘｅｃ２项测试指标下的性能开销远大于其他指标．这是因为在这２项指标的测试过程中都需要计算可执行文件的Ｈａｓｈ值．在ｆｏｒｋ＋ｅｘｅｃ测试中执行了ｈｅｌｌｏＷｏｒｌｄ应用程序（６ＫＢ），而在ｂａｓｈ＋ｅｘｅｃ测试分别执行了ｂａｓｈ（７００ＫＢ）和ｈｅｌｌｏＷｏｒｌｄ两个程序．为了进一步研究影响ＶＭＧｕａｒｄ性能开销的因素，我们将ＶＭＧｕａｒｄ执行流程分解为３个步骤：１）系统调用截获；２）程序路径定位；３）程序文件测量；并分别测量各个步骤所引入的性能开销．测试结果如表４所示．ＶＭＧｕａｒｄ主要的性能开销在于测量程序文件的指纹．ｂａｓｈ＋ｅｘｅｃ测试中，ＶＭＧｕａｒｄ－Ｑｅｍｕ执行文件测量所花费的时间几乎是标准Ｑｅｍｕ原始执行时间的１倍（１０５％），而ＶＭＧｕａｒｄ－ＫＶＭ的情况也基本相同（１０２％）．然而，与表３中的数据对比发现，ＶＭＧｕａｒｄ－Ｑｅｍｕ性能开销为１９ ０５５－９ ０８７＝９ ９６８μｓ，几乎是ＶＭＧｕａｒｄ－ＫＶＭ性能开销的２倍．Ｔａｂｌｅ ４ Ｂｒｅａｋｄｏｗｎ ｏｆ ＶＭＧｕａｒｄ Ｏｖｅｒｈｅａｄ表４ ＶＭＧｕａｒｄ性能开销的分解表示％Ｏｖｅｒｈｅａｄｆｏｒｋ＋ｅｘｅｃ ｂａｓｈ＋ｅｘｅｃＱｅｍｕ ＫＶＭ Ｑｅｍｕ ＫＶＭＳｙｓｔｅｍ Ｃａｌｌ Ｉｎｔｅｒｃｅｐｔｉｏｎ ０．７ ６．２ ０．４ ９．０Ｐａｔｈ Ｉｎｆｅｒｒｉｎｇ １．７ ０．９ ４．４ ３．２Ｍｅａｓｕｒｅｍｅｎｔｓ（ｈａｓｈ）３．９ ３．１ １０５．０ １０２．１ 为此，我们进一步分析了程序文件测量中可能影响性能的因素．首先，２种实现方式下采用完全相同的方法计算文件的Ｈａｓｈ值；其次，测量时需要根据客户文件系统的元数据信息定位到文件数据块，但由于文件路径不深，且索引信息均位于内存中，因而开销基本可以忽略不计；最后，在对文件内容做Ｈａｓｈ前，需要首先将文件内容读入内存，其中涉及多次文件读取操作．通过分析发现，由于ＶＭＧｕａｒｄ－Ｑｅｍｕ是用户态进程，需要通过系统调用来访问文件系统中的文件；而ＶＭＧｕａｒｄ－ＫＶＭ位于内核态执行，可以通过内核函数直接访问文件系统，因此节省了处理时间．３．２．２ 应用程序基准测试为了进一步评测ＶＭＧｕａｒｄ的性能，我们采用６种常用应用程序来测试其性能开销，如表５所示：Ｔａｂｌｅ ５ Ａｐｐｌｉｃａｔｉｏｎｓ ｆｏｒ Ｅｖａｌｕａｔｉｏｎ表５ 基准测试应用程序Ｉｔｅｍ ＣｏｍｍａｎｄＧｅｔｐｉｄ（２０００ｒｕｎｓ）ｇｅｔｐｉｄ－２０００．ｓｈＤｅｃｏｍｐｒｅｓｓｉｏｎ（ｂｚ２）ｔａｒ ｚｘｆ ｌｉｎｕｘ－ｓｏｕｒｃｅ．ｔａｒ．ｂｚ２Ｃｏｍｐｒｅｓｓｉｏｎ（ｇｚ）ｔａｒ ｚｃｆ ｌｉｎｕｘ－ｓｏｕｒｃｅ－ｄｉｒＦｉｌｅ Ｃｏｐｙ ｃｐ－ｒ ｌｉｎｕｘ－ｓｏｕｒｃｅ－ｄｉｒ ｏｔｈｅｒｗｈｅｒｅＫｅｒｎｅｌ Ｂｕｉｌｄ ｍａｋｅ ｄｅｆｃｏｎｆｉｇ ＆ｍａｋｅＬｉｎｕｘ Ｂｏｏｔ Ｌｉｎｕｘ ｂｏｏｔ 图５（ａ）（ｂ）分别给出了ＶＭＧｕａｒｄ－Ｑｅｍｕ和ＶＭＧｕａｒｄ－ＫＶＭ的应用程序基准测试结果．从整体趋势上看，ＶＭＧｕａｒｄ－ＫＶＭ与ＶＭＧｕａｒｄ－Ｑｅｍｕ相比性能开销较大．其原因是ＶＭＧｕａｒｄ－ＫＶＭ需要通过强制触发页错误异常使当前执行流程陷入ＶＭＭ层，来截获上层系统调用，因此一定程度上影响了性能．对于ｇｅｔｐｉｄ测试程序，我们通过重复执行ｇｅｔｐｉｄ程序２ ０００次来模拟最坏情况．其中，该程序的唯一操作就是执行ｇｅｔｐｉｄ系统调用，因此与其他测试应用程序相比，ＶＭＧｕａｒｄ所引入的性能开销相对较高．如图５所示，对于压缩和解压缩程序，ＶＭＧｕａｒｄ－Ｑｅｍｕ和ＶＭＧｕａｒｄ－ＫＶＭ分别引入了１．７％和２．７％的性能开销．这２种程序均为计算密集型作业，性能开销较小．文件拷贝是Ｉ?Ｏ密集型作业，其中包含大量的读写操作．而ＶＭＧｕａｒｄ截获了ｗｒｉｔｅ系统调用来防止对加载后软件文件的修改，因此系统开销相对较大．内核编译耗时较长，其中会重复加载少量应用程序和动态链接库，如ｍａｋｅ，ｇｃｃ和ｌｉｂ．ｓｏ等．如图５所示，ＶＭＧｕａｒｄ给内核编译带来的性能开销较小，特别是ＶＭＧｕａｒｄ－Ｑｅｍｕ，其开销基本可以忽略不计．这是由于ＶＭＧｕａｒｄ在完整性验证过程中通过缓存机制避免重复计算可执行文件的Ｈａｓｈ值，从而大大减少了性能开销．Ｌｉｎｕｘ启动可用于全面测试ＶＭＧｕａｒｄ的性能开销，因为Ｌｉｎｕｘ启动过程中会加载ＶＭＧｕａｒｄ验证的全部３种类型的可执行程序．ＶＭＧｕａｒｄ－ＫＶＭ的性能开销接近４４４１计算机研究与发展 ２０１１，４８（８）。
abstracthardwareabstractionlayer类方法-回复AbstractHardwareAbstractionLayer类方法是一个用于将硬件的底层操作抽象化的类方法。
在计算机科学领域中，硬件抽象层是一个重要的概念，用于隐藏底层硬件的实现细节并提供一致的接口供更高级别的软件使用。
在本文中，我将一步一步解释AbstractHardwareAbstractionLayer类方法的工作原理，并讨论其在软件开发过程中的应用。
第一步是了解硬件抽象层的概念。
硬件抽象层是在操作系统和硬件之间的一层软件接口。
它的目标是将硬件的底层细节隐藏起来，以便应用程序可以更容易地与硬件进行交互。
硬件抽象层可以提供面向对象的接口，抽象化硬件的各个功能和特性，使得应用程序开发人员无需了解特定硬件的细节就能够编写跨平台的代码。
第二步是理解AbstractHardwareAbstractionLayer类方法的作用。
该类方法是在软件开发中使用的一个工具，它通过提供一组抽象化的硬件接口，使得开发人员能够更轻松地编写跨平台的代码。
它可以屏蔽不同硬件之间的差异，并提供一致的接口，简化了软件开发过程中对底层硬件的操作。
第三步是了解AbstractHardwareAbstractionLayer类方法的具体实现方式。
该类方法可以通过使用面向对象编程的技术来实现。
它可以定义一组抽象类或接口，用于描述硬件的各个功能和特性。
然后，针对特定的硬件，可以实现相应的具体类来实现这些抽象类或接口，并提供底层硬件的具体实现。
通过抽象类或接口的使用，开发人员可以通过简单地调用这些抽象类或接口来使用硬件，而不需要了解底层硬件的细节。
第四步是讨论AbstractHardwareAbstractionLayer类方法在软件开发中的应用。
该类方法可以提供一种统一的接口，使得开发人员可以更容易地编写跨平台的代码。
通过将硬件操作抽象化，应用程序可以在不同的硬件平台上运行，而无需针对每个平台编写特定的代码。
第34卷第1期2017年1月计算机应用与软件Computer Applications and SoftwareVoL34 No.1Jan.2017—种Symmetric NAT穿透的新方法冯金哲殷海兵(中国计量学院信息工程学院浙江杭州310018)摘要NAT(Network Address Translator)不仅解决了I P地址短缺的问题，而且也使内网主机避免了来自网络外部的攻击。
但对于P2P应用来说，需要建立端到端的连接，所以说如何穿透N A T成为了P2P技术中的一个关 键。
通过对当前N A T穿透技术的研究，发现依靠TURN(Traversal Using Relay N A T)来实现对Symmetric N A T穿透往往存在服务器负担重、延时、丢包的问题，于是给出一种基于端口预测的N A T穿透新方法。
该方法避免了依 靠T U R N来实现对Symmetric N A T穿透所带来的难题，大大满足了对网络安全要求高而使用对称型N A T企业的 需求。
关键词Symmetric N A T T U R N P2P N A T穿透中图分类号TP393 文献标识码A D O I：10. 3969/j. issn. 1000-386x. 2017. 01.022A NEW METHOD FOR SYMMETRIC NAT TRAVERSALFeng Jinzhe Yin Haibing{College of Information Engineering ,China Jiliang University, Hangzhou 310018, Zhejiang, China)Abstract N A T(Network Address Translator) not only solves the problem of IP address shortage, but also makes the network host avoid the attacks from outside the networks. But for P2P application,i t needs to establish an end-to-end connection,so how to realise N A T traversal becomes a key in P2P technology. Based on the research of current N A T traversal technology,we found that to achieve Symmetrical N A T traversal relying on T U R N(Traversal Using Relay N A T) often has the problems of heavy server burden,time delay and packet loss. Therefore,in this paper we present a new N A T traversal method by using port prediction, the method avoids the problems brought by relying T U R N to implement traversal of symmetrical N A T,and greatly satisfies the requirements of those enterprises who have high demand on network security and thus use symmetric NAT.Keywords Symmetrical N A T T U R N P2P N A T traversal〇引言网络地址转换[1]N A T是一个非常有名的工具，能 够使I P地址在网络上重用。
第19卷 第6期 太赫兹科学与电子信息学报Vo1.19，No.62021年12月 Journal of Terahertz Science and Electronic Information Technology Dec.，2021文章编号：2095-4980(2021)06-1008-06基于强跟踪五阶容积卡尔曼滤波的眼睛跟踪算法殷晓春1a，蔡晨晓2，李建林1b(1.南京信息职业技术学院 a.人工智能学院；b.网络与通信学院，江苏南京 210023；2.南京理工大学自动化学院，江苏南京 210094)摘 要：非侵入式眼睛跟踪在许多基于视觉的人机交互应用中扮演十分重要的角色，但由于眼睛运动的强非线性，如何确保眼睛跟踪过程中对外界干扰的鲁棒性以及跟踪精确度是其应用的关键问题。
为提高眼睛跟踪的鲁棒性和精确度，提出强跟踪五阶容积卡尔曼滤波算法(ST-5thCKF)，将强跟踪滤波(STF)次优渐消因子引入具有接近最少容积采样点且保持五阶滤波精确度的五阶容积卡尔曼滤波(5thCKF)，获取5thCKF对强非线性良好滤波精确度同时具备STF对外界干扰的鲁棒性。
真实条件下的实验结果验证了所提算法在眼睛跟踪中的有效性。
关键词：眼睛跟踪；强跟踪滤波；五阶容积卡尔曼滤波；强跟踪五阶容积卡尔曼滤波中图分类号：TP391.4 文献标志码：A doi：10.11805/TKYDA2020427Eye tracking algorithm based on strong tracking fifth-degree cubature Kalman filterYIN Xiaochun1a，CAI Chenxiao2，LI Jianlin1b(1a.Institute of Artificial Intelligence；1b.School of Network and Communication，Nanjing Vocational College of Information Technology，Nanjing Jiangsu 210023，China；. All Rights Reserved.2.School of Automation，Nanjing University of Science and Technology，Nanjing Jiangsu 210094，China)Abstract：Non-intrusive eye tracking plays an important role in many vision-based human computer interaction applications. How to ensure the robustness of external interference and tracking precisionduring eye tracking is the key problem to its applications owing to the strong nonlinearity of eye motion.To improve the robustness and precision of eye tracking, the Strong Tracking fifth-degree CubatureKalman Filter(ST-5thCKF) algorithm is proposed. The algorithm introduces the suboptimal fading factor ofStrong Tracking Filter(STF) into fifth-degree Cubature Kalman Filter(5thCKF) which almost has the leastcubature sampling points while maintaining the fifth-degree filtering accuracy. The proposed algorithmbears the high filtering precision to strong nonlinearity of 5thCKF, as well as the robustness to externalinterference of STF. The experimental results under practical conditions show the validity of the proposedalgorithm in eye tracking.Keywords：eye tracking；Strong Tracking Filter(STF)；fifth-degree Cubature Kalman Filter(5thCKF)；Strong Tracking fifth-degree Cubature Kalman Filter(ST-5thCKF)眼睛跟踪对于提高日常人机交互的质量具有重要作用，在司机疲劳驾驶检测[1-4]、虚拟现实系统(Virtual Reality System，VR)的图像扫描、飞行人员行为检测[5]、眼睛与电脑交互[6]等领域得到广泛应用。
Fortinet Delivers Automated, Advanced Security for VMware NSX-T EnvironmentsExecutive SummaryVMware NSX-T, a stand-alone software-defined networking (SDN) platform,addresses the use cases that NSX-V does not support. NSX-T is expected tobe widely adopted in the coming year as enterprises increasingly use multiplehypervisors, containers, and multiple clouds.While NSX-T provides basic firewall capabilities, organizations facing expandingdigital attack surfaces need more. FortiGate VM for NSX-T augments VMwaresecurity with robust protection for both east-west and north-south traffic. Avirtual appliance that integrates with NSX-T Data Center through service insertionas a third-party edge firewall, FortiGate VM performs next-generation firewalling(NGFW), inspection of encrypted secure sockets layer (SSL)/transport layersecurity (TLS) traffic, intrusion prevention (IPS), and web application control.Fortinet is one of the first security vendors that delivers complete integration withthe NSX-T Data Center 2.4, 2.5, 3.0 and 3.1 releases.Cloud Adoption Expands Attack SurfaceRapid cloud adoption means a rapidly expanded attack surface. A recent surveypredicts that 83% of enterprise workloads will be in the cloud by 2020.1 Further,based on recent research, the average enterprise uses as many as 91 differentcloud applications.2 Most of these are adopting multi-cloud approaches, whichresult in security silos that obfuscate security visibility and make it difficult tomanage them through centralized controls.Clearly, there is no shortage of attack vectors. Cloud workloads and applications,whether in the public or private cloud, or Software-as-a-Service (SaaS), must beprotected from sophisticated threats with reliable, elastic security.3Encrypted Traffic at a Record HighAs more and more data is migrated from on-premises data centers to the cloud, thisdramatically expands the amount of encrypted traffic traversing the internet. Onestudy finds that more than 72% of internet traffic is now encrypted.4While encrypted traffic protects data from bad actors, it is not without its risks.Cyber criminals are increasingly using it to deliver malware into their intendedtargets. Unless this encrypted traffic is inspected with the right security tools, anorganization can suddenly find itself facing a potential data breach or operationaldisruption. But many next-generation firewall (NGFW) solutions either lack securesockets layer (SSL)/transport layer security (TLS) inspection capabilities or theperformance to conduct inspections without adding more NGFWs—and thus cost.SOLUTION BRIEF Joint Solution Components n Fortinet FortiGate n VMWare NSX-T Top Features: n Advanced threat prevention for VMware NSX-T SDDC environments n Automated deployment and orchestration of FortiGate VM for SDDCs and private and public clouds n Single-pane-of-glass management and full visibility with FortiManager n Seamless security scaling from SDDCs to private and public clouds n Inspection of encrypted traffic without impacting network performanceFortinet Support for NSX-T Data CenterNSX-T connects all types of applications and is multi-hypervisor aware. It is an SDN stack that supports hypervisors beyond vSphere, such as KVM and OpenStack. In addition, it supports container platforms such as Kubernetes and Docker.The FortiGate VM next-generation firewall (NGFW) integrates with NSX-T to provide security for hypervisors and container orchestration platforms. This results in seamless and consistent security for the applications running on these platforms. It provides purpose-built integration for VMware’s software-defined data center (SDDC) and interoperability with NSX-T through service insertion as a third-party edge firewall.FortiGate VM also protects the north-south (vertical) traffic flow inside the NSX-T environment. It does so, as depicted in the diagram below, by integrating with logical routers in tier 0 and/or 1, depending on where to inspect the traffic. NSX-T connects workloads running in SDDCs and public and private clouds. FortiGate VM enforces security at the connection points between these disparate networks.Fortinet AdvantagesThe Fortinet Security Fabric delivers a more comprehensive and faster response to threats, while enabling organizations to realize improved efficiencies. Specific operational advantages include:• Automatic identification and containment of threats in real time• Seamless security scaling from data centers to clouds• Compatibility with new versions of VMware on AWS• Smooth failover with active/passive high availability (HA)• Improved efficiency with single-pane-of-glass management and visibility with FortiManager• Ability to examine encrypted traffic with no network slowdownThe Security Fabric also offers threat-intelligence advantages that include:• Integrated, comprehensive security posture across the network with sandbox and content security integration via the Fortinet Security Fabric• The latest threat intelligence delivered in near real time by FortiGuard Labs• Efficient, top-rated protection for disparate multi-cloud environmentsThe Best Way to Secure NSX-T EnvironmentsIf you are running NSX-T, you need dynamic security that can enforce security policy across multi-hypervisor and container environments. FortiGate VM integration with VMware’s NSX-T solution extends the NSX-T firewall functionality with advanced security services and allows enterprises to reap all the benefits of SDDCs and public and private clouds with agility and efficiency.Advanced Layer 7 security with FortiGate VM for traffic moving between virtual machines and external networks secures customer assets and data in the cloud against even the most sophisticated threats. FortiGate VM includes multi-layered protections such as firewall, application control, IPS, sandboxing, and threat-protection technologies.1 Louis Columbus, “83% Of Enterprise Workloads Will Be In The Cloud By 2020,” Forbes, January 7, 2018.2 Scott Brinker, “The average enterprise uses 91 marketing cloud services,” Chief Marketing Technologist Blog, June 12, 2017.3 “Quarterly Threat Landscape Report Q3 2018,” Fortinet, November 2018.3 John Maddison, “More Encrypted Traffic,” Fortinet Blog, December 10, 2018. Copyright © 2021 Fortinet, Inc. All rights reserved. Fortinet, FortiGate, FortiCare and FortiGuard, and certain other marks are registered trademarks of Fortinet, Inc., and other Fortinet names herein may also be registered and/or common law trademarks of Fortinet. All other product or company names may be trademarks of their respective owners. Performance and other metrics contained herein were attained in internal lab tests under ideal conditions, and actual performance and other results may vary. Network variables, different network environments and other conditions may affect performance results. Nothing herein represents any binding commitment by Fortinet, and Fortinet disclaims all warranties, whether express or implied, except to the extent Fortinet enters a binding written contract, signed by Fortinet’s General Counsel, with a purchaser that expressly warrants that the identified product will perform according to certain expressly-identified performance metrics and, in such event, only the specific performance metrics expressly identified in such binding written contract shall be binding on Fortinet. For absolute clarity, any such warranty will be limited to performance in the same ideal conditions as in Fortinet’s internal lab tests. Fortinet disclaims in full any covenants, representations, and guarantees pursuant hereto, whether express or implied. Fortinet reserves the right to change, modify, transfer, or otherwise revise this publication without notice, and the most current version of the publication shall be applicable.June 23, 2021 10:07 AM。
VM-FIT:Supporting Intrusion Tolerance with Virtualisation TechnologyHans P.Reiser Departamento de Informática Universidade de Lisboa,Portugal hans@di.fc.ul.ptRüdiger KapitzaDepartment of Compter Science4 University of Erlangen-Nürnberg,Germany kapitza@cs.fau.deABSTRACTThe use of virtualisation technology on modern standard PC hardware has become popular in the recent years.This paper presents the VM-FIT architecture,which uses virtu-alisation for realising fault and intrusion tolerant network-based services.The VM-FIT infrastructure intercepts the client–service interaction at the hypervisor level,below the guest operating system that hosts a service implementation, and distributes requests to a replica group.The hypervi-sor is fully isolated from the guest operating system and provides a trusted component,which is not affected by ma-licious intrusions into guest operating system,middleware, or service.Furthermore,the hypervisor allows the imple-mentation of more efficient strategies for proactive recovery in order to cope with the undetectability of malicious intru-sions.Categories and Subject DescriptorsD.4.5[Operating Systems]:Reliability—Fault-tolerance;C.4[Performance of Systems]:Fault toleranceGeneral TermsReliabilityKeywordsVirtualisation,Byzantine fault tolerance,proactive recovery, innovative system architectures1.INTRODUCTIONServices in distributed systems have become omnipresent, and the reliability of such services is becoming an increas-ingly significant issue for a growing class of applications.In the area of fault-tolerant systems,the toleration of malicious intrusions is one of the most difficult challenges.In order to enable the use of intrusion-tolerant concepts in a wide range of application domains,light-weight and efficient concepts are needed.This paper investigates the use of virtualisation technol-ogy for the construction of fault and intrusion tolerant sys-tems.Virtualisation provides a hypervisor component that is fully isolated from the guest operating system that hosts the actual service implementations.We identify two poten-tial gains from virtualisation technology:First,the hyper-visor is able to provide an isolated trusted component that does not have all the vulnerabilities of the guest systems hosting the actual service.Second,the hypervisor has full control over the guest systems,and thus can support an efficient proactive recovery of the guest system instances. The paper is structured as follows.The next section dis-cusses related work.Section3describes the core concepts of the VM-FIT(virtual machine–fault and intrusion tol-erance)system architecture.Section4presents details of our current prototype implementation and discusses future work.Finally,Section5concludes.2.BACKGROUND AND RELATED WORK Frequently,software-based replication schemes are im-plemented in middleware systems such as fault-tolerant CORBA[12].Most systems assume a crash-stop behaviour of nodes and cannot tolerate non-benign faults such as un-detected random bit errors in memory,invalid states caused by software faults,or malicious intrusions of an attacker. Handling that kind of faults is the aim of Byzantine fault-tolerant mechanisms,such as the Castro-BFT algorithm[4] and the intrusion-tolerant SINTRA architecture[3].One problem of intrusion-tolerant systems is that compromised components may remain undetected for extended periods of time.In the course of time,an attacker might obtain con-trol of an increasing number of nodes,finally exceeding the maximum number of faulty nodes that the system is able to tolerate.Proactive recovery[13,5,16]is a technique that periodically refreshes nodes in order to remove poten-tial intrusions;as a side effect,the refresh operation may also deploy new software versions that eliminate known vul-nerabilities.Virtualisation is an old technology that was introduced by IBM in the1960s[8].Systems such as Xen[1]and VMware [17]made this technology popular on standard PC hardware. Virtualisation enables the execution of multiple operating system instances simultaneously in isolated environments on a single physical machine.While mostly being used for issues related to resource management,virtualisation can also be used for constructing fault-tolerant systems.Bressoud and Schneider[2]demon-strated the use of virtualisation for lock-stepped replicationof an application on multiple hosts.Besides such direct replication support,virtualisation can also help to encapsu-late and avoid faults.The separation of system components in isolated virtual machines reduces the impact of faulty components on the remaining system[11].Furthermore,the separation simplifies formal verification of components[18]. Using virtualisation is also popular for intrusion detection and analysis.Several systems transparently inspect a guest operating system from the hypervisor level[6,7].The RESH architecture[15]proposes redundant execution of a service on a single physical host using virtualisation. This approach allows the toleration of non-benign random faults such as undetected bit errors in memory,as well as N-version programming in order to tolerate software faults. The contributions of this paper towards virtualisation-based intrusion tolerance differ from previously published approaches.Unlike strictly-coupled replication systems,we aim at replicating network-based services across heteroge-neous nodes,using asynchronous communication networks. We use virtualisation to supply all nodes with a trusted en-tity that is fully isolated from the potentially faulty guest domain,which hosts a service together with an operating system and a middleware environment.Active replication of a service is complemented with support for proactive recov-ery,in order to eliminate potentially undetected intrusions into the guest domains.This way,we obtain mechanisms for proactive recovery that are more efficient than previous solutions.3.VM-FIT ARCHITECTUREThe VM-FIT architecture provides generic support for the replication of network-based services.It transparently in-tercepts remote communication at the hypervisor level,and provides support for proactive recovery.We assume that the following properties hold:•Clients use a request–reply interaction to access a re-mote network-based service.•The service has deterministic behaviour,i.e.,the ser-vice state and the replies sent to clients are uniquely defined by the initial state and the sequence of incom-ing requests.•Byzantine faults may occur in a limited number of ser-vice replicas.Thefirst assumption allows the interception of client–service interaction at the network level.Together with the second assumption,the usual model for deterministic state machine replication is used.The failure model of the third assumption will be specified in more detail later on.In the following,we adopt a terminology that is inspired by the Xen hypervisor[1].The hypervisor is a minimal layer running at the bare hardware.On top,service in-stances are executed in guest domains,and a privileged Do-main0controls the creation and execution of the guest do-mains.In the following,we introduce the terminology of a Domain NV(network/voting),which handles the communi-cation with clients and among replicas,and the voting over replica replies.The Domain NV is fully isolated from all guest domains.It may or may not be integrated into the usual Domain0.Figure1:VM-FIT basic replication architecture 3.1Replication SupportThe basic system architecture is shown in Figure1.The service replicas are running in isolated virtual machines in Domain Guest.The network interaction from client to the service is handled by the replication manager in the sepa-rate Domain NV.This manager intercepts the client connec-tion and distributes all requests to the replica group using a group communication system.Each replica processes the client requests and sends a reply to the node that accepted the client connection.At this point,the replication manager selects the correct reply for the client using majority voting. Thefirst benefit from this architecture is a transparent interception of the client–service interaction,independent of the guest operating system,middleware,and service im-plementation.As long as the assumption of determinis-tic behaviour is not violated,the service replicas may be completely heterogeneous,with different operating systems, middleware,and service implementations.The second benefit from this architecture is the support for a composite fault model.The architecture is composed of multiple isolated elements(Domain NV,Domain0,Domain Guest),and each element may be subject to failures.For VM-FIT,we consider two possible variants:•All system elements are potentially affected by Byzan-tine faults.•The Domain NV(which contains the basic replica-tion logic and network functionality,including network driver,communication stack,and group communica-tion protocol)fails only by crash-stop of the complete host.The Domain Guest uses a Byzantine fault model, and thus can be subject to malicious intrusion.The same Byzantine model can be applied to the Domain 0,as long as the system makes sure that Domain NV is an protected,isolated entity that cannot be influenced from Domain0.Thefirst variant is more powerful in terms of tolerable faults.It is able to tolerate intrusions even in the Do-main NV.The drawback of this approach is that it requires more complex,Byzantine fault tolerant group communica-tion protocols,compared to the second variant.The second variant can be justified if the guest domain is a complex system with a legacy OS and a full-blown middle-ware,whereas the Domain NV executes in a fully isolated, lean domain.In the extreme case,the Domain NV could be an entity that can be subjected to full formal verifica-tion.In this case,simple,crash-stop group communication protocols can be used for distributing client requests.Thus, implementing consistency mechanisms in the privileged do-main is expected to allow more efficient protocols than in systems that aim at tolerating Byzantine faults in all com-ponents of the system.Because of this aspect,we expect that our approach is best used in situations in which the first variant can be used.As a result,we obtain a hybrid system architecture that is able to use simple protocols for replication control,while still being able to tolerate mali-cious intrusions in the Domain Guest of a limited number of nodes.In the case of a crash-stop Domain NV,the architecture can use majority voting for verifying client replies.In this case,the number of replicas must be n≥2f+1in order to tolerate up to f Byzantine faulty replica instances.In Section4.4,we consider the execution of the group com-munication protocol in the non-crash-stop domains.In this case,Byzantine fault tolerant protocols are needed,which require n≥3f+1nodes.3.2Proactive RecoveryProactive recovery increases the resilience of the replicated service,as the faulty nodes become rejuvenated periodically, and thus the upper bound of f tolerable faults is no longer required for the whole system lifetime,but only for the du-ration of a rejuvenation cycle.Proactive recovery requires a system component that controls the re-initialisation of the local service instance(including the operating system and middleware).For example,a tamper-proof external hard-ware might be used for rebooting the node from a secure code image.It is not feasible to trigger the recovery within a service replica,as a malicious intrusion might cause the replica component to ignore the required recovery.In the VM-FIT architecture,the Domain NV can be used as a trusted entity that is able to completely re-initialise the target domain that hosts the service.For this purpose, all elements(i.e.,operating systems,middleware,and ser-vice instance)need to be initialised with a“clean”state, by securely obtaining the service state from other replicas. As discussed by Sousa et al.[16],the recovery of a node has an impact on either the ability to tolerate faults or on the system availability.The VM-FIT architecture avoids the costs of using additional spare replicas for maintaining availability during recovery.Instead,it accepts the tempo-rary unavailability during recovery,and uses the advantages of virtualisation in order to minimise this unavailability. Unlike other approaches to proactive recovery,the hyper-visor-based approach permits the initialisation of the reju-venated replica instance concurrent to the execution of the old instance.The hypervisor is able to instantiate a second Domain Guest on the same hosts.After initialisation,the replication coordinator can shut down the old replica and trigger the activation of the new one.This way,the down-time of the service replica is minimised to the time necessary for the coordinated transition with a consistent state.The state of the rejuvenated replica needs to be initialised on the basis of a consistent checkpoint of all replicas.As replicas may be subject to Byzantine faults and thus have an invalid state,the state transfer has to be based on an majority agreement of all replicas.For this purpose,the VM-FIT architecture is able to exploit the locality of the old replica version on the same host.The actual state is transferred locally,with a verification of its validity on the basis of checksums obtained from other replicas.Only if the local state is invalid,a remote state transfer becomes necessary.We discuss this state-transfer issue in more detail in the Section4.3.In summary,virtualisation allows a secure proactive re-covery of service instances without additional hardware sup-port.At the same time,it minimises downtime during recov-ery by creating a new replica instance in parallel to the run-ning instance,and it enhances the state-transfer efficiency by transferring local state.3.3Application AreasThe proposed VM-FIT architecture can be applied to var-ious kinds of applications,ranging from simple web applica-tions to critical infrastructure.Applications using VM-FIT, however,have to meet the constraints defined at the start of this section.The implementation of new intrusion-tolerant applications using VM-FIT is the easier variant.In this case,the devel-oper is aware of the constraints of the service replication. Specifically,the application can make the guarantee of be-ing deterministic,can provide interfaces for state transfer, and strictly adhere to a state machine principle.It might,however,also be desirable to apply the VM-FIT architecture to existing services without or with only min-imal modifications.This approach requires several steps. First,it must be verified if the application behaviour is strictly deterministic.One source of nondeterminism that is found in many applications is the support for multithread-ing.Handling multiple client requests with independent threads easily violates the state-machine principle by ap-plying state changes to replicas in an inconsistent order.A further problem is the use of local address data in requests and replies.Each replica uses a different local communica-tion address that is only known to the replication controllers in Domain NV,and in all communication with the external clients,the“outer”address of Domain NV has to be used. Because of these problems,we anticipate that the VM-FIT architecture cannot be used for transparently making ex-isting applications intrusion tolerant.This does not mean that the architecture is useless for such existing services.As an example,in the next section we illustrate how a proto-type implementation of VM-FIT can be used to replicate CORBA-based services.4.PROTOTYPE IMPLEMENTATIONWe have implemented a simple prototype of VM-FIT, which enables the transparent replication of a CORBA-based service.In the prototype,the Xen3.0hypervisor was used with Linux as operating system for Domain0and for Domain Guest.This virtualisation software has reached a high level of maturity,is available as open source,and sup-ports a wide range of guest operating systems.This broad support is essential for the envisioned goal of providing a generic interception and replication architecture that is in-dependent from specific operating systems.4.1Implementation DetailsIn thefirst prototype,no attempts towards formal verifi-cation of the trusted component have been made.Indeed, the same operating system,an off-the-shelf Linux distribu-tion,is used for Domain0and Domain Guest,and Domain NV is integrated into Domain0.As a consequence,vulnera-bilities at the operating system level are currently present in both domains.We expect,however,that this is only a lim-itation of the early prototype.For future work,we envision two potential options.Thefirst variant uses Xen as basic hypervisor,but—instead of Linux—uses a minimalist oper-ating system in Domain NV.The second variant is based on the L4ka microkernel[10].This microkernel offers virtuali-sation functionality.In addition,significant efforts towards a formal verification of the L4kernel have been made by other researchers[18].These results provide an excellent basis for a trusted entity.A core task of the Domain NV is the provision of mecha-nisms for the instantiation and initialisation of service repli-cas.A simple description language enables the developer to describe how the privileged domain has to instantiate a local replica in a new guest virtual machine.Currently,a disk image of a Xen virtual machine with a preconfigured operating system and middleware environment is provided. After initialisation,as well as after recovery,a state trans-fer from the set of replicas is required.The actual transfer is described below;a prerequisite for the transfer is the seri-alisation of the replica state into a byte stream.We use an application-controlled serialisation mechanism for this pur-pose.This means that the Domain NV can request the service in the Domain Guest to serialise its state.4.2Consistency ManagementThe replication of a CORBA services requires custom mechanisms within the Domain NV.Thefirst reason for this is the addressing mechanisms of CORBA.In CORBA, the remote address of a service is specified as an interopera-ble object reference(IOR).Internally,the IOR contains the TCP/IP address of the object request broker(ORB).In a VM-FIT environment,each replica will create its own IOR, using the local network address.These addresses are private IP addresses only used for communication between the vir-tual machines of a single physical host,and cannot be used by clients.Therefore,the Domain NV of our prototype is able to construct a new service IOR for the replicated ser-vice,and publishes this address to a public naming service. The envisioned hypervisor-based replication architecture can be applied to various kinds of network-based distributed services.For validating the architecture,it is assumed that the service is implemented as a deterministic CORBA ob-ject.Thus,the initialisation of a service object includes the three levels operating system,middleware,and replica ing CORBA objects allow a comparison between replication support at the middleware level and at the hypervisor level.As a basis for realising group communication on Domain NV,we currently use the AGC group communication system [14],which internally uses the Paxos algorithm for message ordering.4.3State Transfer and Proactive Recovery For proactive recovery,every recovery operation requires a consistent checkpoint of a majority of replicas.This check-point has to be transferred to the recovering replica and verified by the majority of nodes(e.g.,by checksums).Fi-nally,the recovering replica has to be reinitialised by the provided state.In our prototype,we assume that a secure code basis for the replica is available locally,and only the data state is required to initialise the replica.The checkpointing and state transfer are time-consuming operations.Furthermore,their duration depends on the state size.During the checkpoint operation,a service is not accessible by clients;otherwise,concurrent state-modifying operations might cause an inconsistent checkpoint.Conse-quently,there is a trade-offbetween service availability and safety gained by proactive recovery given by the recovery frequency of replicas.To reduce the unavailability of a ser-vice,while still providing the benefits offered by proactive recovery,more than one replica could be recovered at a time. However,in previous systems with dedicated hardware for triggering recovery,the number of replicas recovering in par-allel is limited by the fault assumption,as every recovering replica reduces the number of available nodes in a group and,consequently,the number of tolerable faults.The VM-FIT architecture is able to offer a parallel recov-ery of all replicas at a time by doing all three steps nec-essary for proactive recovery in parallel.If service replicas have to be recovered,every node receives a checkpoint mes-sage and determines the replica state.The Domain NV re-ceives this state and prepares a shadow replica domain.This domain will later be used replace the existing local replica instance and is initialised by the state transfer operation. Thereby,the state is provided as a stream and checksums on the stream data are generate for a configurable block size. These checksums are distributed to all other nodes hosting replicas of the service.Before a certain block is used for the initialisation of the shadow replica,it has to be veri-fied by the majority of all state-providing replicas via the checksums.If a block turns out to be faulty,it is requested from one of the nodes of the majority.After the state trans-fer,every replica has a fully initialised shadow replica that is a member of the replication group.In afinal step,the old replicas can be safely shutdown as the shadow replicas already substitute them.This approach reduces the downtime due to checkpointing to one checkpoint every recovery period.Furthermore,the amount of transferred data over the network is reduced as only faulty blocks have to be requested from other nodes. Finally,the state transfer is sped up in the average case as only checksums have to be transferred.4.4Future WorkThe current prototype enables an early evaluation of the core VM-FIT architecture.In future work,we plan to pro-vide a detailed qualitative and quantitative evaluation of the system properties.For an experimental evaluation of the performance of the system,fault injection allows to simulate the effect of non-benign faults in the system to some extent. We plan to use[9]as a platform for executing such exper-iments.The results will not only provide an assessment of VM-FIT,but also will also permit a comparison with other replication infrastructures,such as a fault-tolerant CORBA implementation.Another issue of future work is the applicability of VM-FIT to other existing distributed services.The CORBA replication prototype has shown that,for existing services,dedicated support for these infrastructures has to be inte-grated into the Domain NV.We will discuss what extensions will be required for other,non-CORBA applications.An even more important issue is the trust into the Domain NV.Currently,no real mechanisms are used to substantiate this trust.In the future,it is essential to replace the complex domain NV(replication controller application on top of a full Linux instance)with a leaner alternative.In the extreme case,a complete formal verification of Domain NV might be desirable.Our prototype current implements group communication in the privileged Domain NV.In order to minimise the amount of code in the privileged domain,the advantages and disadvantages of handling group communication here or at the application layer need to be discussed.The exist-ing AGC architecture could be used for a hybrid approach, which provides some basic services(such as distributed con-sensus)in the privileged part,which acts as a trusted base, and the remaining part of the group communication proto-col is handled in the guest operating systems.Such a hybrid architecture is highly promising and feasible to implement within a short time on the basis of the existing system. 5.CONCLUSIONSIn this paper,we have investigated the use of virtualisa-tion technology for the construction of fault and intrusion tolerant systems.The VM-FIT architecture provides ba-sic support for transparent intrusion-tolerant replication of services and for proactive recovery of replicas.In this archi-tecture,virtualisation is used to provide a trusted compo-nent on each machine.This enables the use of more efficient protocols.Furthermore,the hypervisor can be used for sup-porting proactive recovery of service instances.Our current prototype enables a detailed investigation of some core is-sues of the VM-FIT architecture.Future work will provide a more detailed quantitative study of dependability and ef-ficiency.6.ACKNOWLEDGEMENTSThis work has been supported by the DAAD.7.REFERENCES[1]P.Barham,B.Dragovic,K.Fraser,S.Hand,T.Harris,A.Ho,R.Neugebauer,I.Pratt,andA.Warfield.Xen and the art of virtualization.InSOSP’03:Proc.of the nineteenth ACM symposiumon Operating systems principles,pages164–177,NewYork,NY,USA,2003.ACM Press.[2]T.C.Bressoud and F.B.Schneider.Hypervisor-basedfault tolerance.ACM put.Syst.,14(1):80–107,1996.[3]C.Cachin and J.A.Poritz.Secure intrusion-tolerantreplication on the internet.In Intl.Conf.onDependable Systems and Networks,pages167–176,2002.[4]M.Castro and B.Liskov.Practical Byzantine faulttolerance.In OSDI’99:Proc.of the third Symposium on Operating Systems Design and Implementation,pages173–ENIX Association,1999.[5]M.Castro and B.Liskov.Proactive recovery in abyzantine-fault-tolerant system.In Fourth Symposiumon Operating Systems Design and Implementation(OSDI),San Diego,USA,Oct.2000.[6]G.W.Dunlap,S.T.King,S.Cinar,M.A.Basrai,and P.M.Chen.ReVirt:enabling intrusion analysisthrough virtual-machine logging and replay.SIGOPSOper.Syst.Rev.,36(SI):211–224,2002.[7]T.Garfinkel and M.Rosenblum.A virtual machineintrospection based architecture for intrusiondetection.In work and Distributed SystemsSecurity Symposium,February2003.[8]R.P.Goldberg.Architecture of virtual machines.InProc.of the workshop on virtual computer systems,pages74–112,New York,NY,USA,1973.ACM Press.[9]H.H¨o xer,M.Waitz,and V.Sieh.Advancedvirtualization techniques for FAUmachine.InR.Spenneberg,editor,11th International LinuxSystem Technology Conference,Erlangen,Germany,September7-10,2004,pages1–12,2004.[10]J.LeVasseur,V.Uhlig,M.Chapman,P.Chubb,B.Leslie,and G.Heiser.Pre-virtualization:softlayering for virtual machines.Technical Report2006-15,Fakult¨a t f¨u r Informatik,Universit¨a tKarlsruhe(TH),July2006.[11]J.LeVasseur,V.Uhlig,J.Stoess,and S.G¨o tz.Unmodified device driver reuse and improved systemdependability via virtual machines.In Proc.of the6th Symposium on Operating Systems Design andImplementation,San Francisco,CA,Dec.2004. [12]O.M.G.(OMG).Common object request brokerarchitecture:Core specification,version3.0.2.OMGdocument formal/02-12-02,2002.[13]R.Ostrovsky and M.Yung.How to withstand mobilevirus attacks(extended abstract).In PODC’91:Proc.of the tenth annual ACM symposium on Principles of distributed computing,pages51–59,New York,NY,USA,1991.ACM Press.[14]H.P.Reiser,U.Bartlang,and F.J.Hauck.Areconfigurable system architecture for consensus-based group communication.In Proc.of the17th IASTEDInt.Conf.on Parallel and Distributed Computing and Systems,pages680–686.IASTED,2005.[15]H.P.Reiser,F.J.Hauck,R.Kapitza,andW.Schrder-Preikschat.Hypervisor-based redundantexecution on a single physical host.In Proc.of the6th European Dependable Computing Conf.,Supplemental Volume-EDCC’06(Oct18-20,2006,Coimbra,Portugal),pages67–68,2006.[16]P.Sousa,N.F.Neves,P.Verissimo,and W.H.Sanders.Proactive resilience revisited:The delicatebalance between resisting intrusions and remainingavailable.In SRDS’06:Proc.of the25th IEEESymposium on Reliable Distributed Systems(SRDS’06),pages71–82,Washington,DC,USA,2006.IEEE Computer Society.[17]J.Sugerman,G.Venkitachalam,and B.-H.Lim.Virtualizing I/O devices on VMware workstation’shosted virtual machine monitor.In Proc.of theGeneral Track:2002USENIX Annual TechnicalConference,pages1–14,Berkeley,CA,USA,2001. [18]H.Tuch,G.Klein,and G.Heiser.Os verification—now!In M.Seltzer,editor,Proc.10th Workshop onHot Topics in Operating Systems(HotOS X),2005.。
