下载文档原格式
外文出处：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。
第44卷第8期自动化学报Vol.44,No.8 2018年8月ACTA AUTOMATICA SINICA August,2018基于粒子滤波的工业控制网络态势感知建模陆耿虹1冯冬芹1摘要粒子滤波(Particlefiltering,PF)算法能有效地对工控系统这一类非线性、非高斯噪声系统进行状态估计,但在实际采用经典粒子滤波状态估计检测攻击时,实验结果显示该方法存在很高的漏检率,无法保障系统安全.因此改进经典算法,提出了基于粒子滤波输入估计的态势理解算法.该算法在考虑系统输入与输出关系的同时,结合蒙特卡洛思想,提取工控系统态势特征,计算态势指标,最终实现态势理解.实验结果表明,该算法能有效地感知持续性攻击,并判断系统态势.关键词工控系统,态势感知,粒子滤波,态势理解引用格式陆耿虹,冯冬芹.基于粒子滤波的工业控制网络态势感知建模.自动化学报,2018,44(8):1405−1412DOI10.16383/j.aas.2017.c160830Modeling of Industrial Control Network Situation Awareness WithParticle FilteringLU Geng-Hong1FENG Dong-Qin1Abstract Particlefiltering(PF)algorithm can estimate the states of industrial control systems,which are non-linear and have non-Gaussian noises.However,when using classical particlefiltering state estimation to detect continuous attacks,it is shown that the false negative rate is too high to ensure the security of the system.Therefore,a situation perception algorithm by means of particlefiltering input estimation is proposed to improve the effectiveness of the classical algorithm.Considering the relationship between system input and output and combining Monte-Carlo simulation,the proposed algorithm can extract industrial control system situation features,calculate situation metrics and realize the situation perception.Experimental results indicate that the proposed algorithm can recognize continuous attacks and judge the system situation effectively.Key words Industrial control system,situation awareness,particlefiltering(PF),situation perceptionCitation Lu Geng-Hong,Feng Dong-Qin.Modeling of industrial control network situation awareness with particle filtering.Acta Automatica Sinica,2018,44(8):1405−1412工控网络处于快速发展阶段,由于工业通信协议中存在不可避免的漏洞,工控网络容易遭受攻击者的恶意攻击,给工控网络的安全带来巨大威胁[1],例如伊朗的震网病毒事件[2],就是攻击者借助Stuxnet病毒对可编程逻辑控制器(Programmable logic controller,PLC)代码进行篡改,实现攻击,从而达到破坏离心机正常运行的恶意目的,并造成不可逆转的严重事故.此外,由于工控网络自身存在的复杂性增加了攻击判断与检测的难度,尤其当管理收稿日期2016-12-19录用日期2017-05-22Manuscript received December19,2016;accepted May22,2017国家自然科学基金(61433006)资助Supported by National Natural Science Foundation of China (61433006)本文责任编委高会军Recommended by Associate Editor GAO Hui-Jun1.浙江大学智能系统与控制研究所工业控制技术国家重点实验室杭州3100271.State Key Laboratory of Industrial Control Technology, Institute of Cyber-Systems and Control,Zhejiang University, Hangzhou310027员处于高压紧张的环境下,更容易发生判断失误[3].因此,如何提高对工控系统网络整体态势的准确判断成为当务之急.1999年,Bass[4]首次将态势感知(Situation awareness,SA)与网络安全技术相结合,以期能准确全面地掌握系统的安全状态,预防事故发生,为安全管理员提供可靠有效的决策依据.Naderpour等[5]提出新型异常态势模型(Abnormal situation modeling,ASM),构建贝叶斯网络对多种态势进行分析,该方法针对安全性要求极高的系统,利用风险指标判断系统在出现异常态势(Abnormal situation)情况下的危险态势(Hazardous situation)风险等级,以此确定系统态势.Kim等[6]提出一个基于贝叶斯推论的核电厂态势评估解析模型,该方法是对核电厂操作员在面对事故发生时的态势评估思考模型(Mental model)建模.以上两种方法,均是在系统出现异常或事故的情况下对系统态势进行分析,其前提是异常或事故1406自动化学报44卷报警为可信的;但是,若系统遭受到欺骗性攻击(例如假数据注入攻击[7]),由于系统内的报警系统被攻击者蒙蔽,此类态势感知技术将无法对系统真实态势进行感知.针对以上问题,结合系统在遭受到攻击的情况下系统内部状态值会发生相应改变,本文提出基于粒子滤波的工业控制网络态势感知建模方法.粒子滤波(Particlefiltering,PF)[8−9]是采用蒙特卡罗仿真完成递推贝叶斯滤波过程,核心是采用一组粒子近似表示系统的后验概率分布,然后使用近似表示估计非线性系统的状态[10].Arulampalam等[11]对PF的非线性/非高斯噪声系统状态的估计性能进行了考察,并将其与扩展卡尔曼滤波进行比较,证明PF能有效解决非线性/非高斯噪声系统的状态估计问题.由上述文献的研究结果可知,传统的PF状态估计,可以预测非线性非高斯系统的态势变化.但是在实际应用PF状态估计算法对工控系统受到的持续攻击进行检测时,实验结果显示漏检率高达96%,这是因为在控制器的作用下,系统从临界状态趋于稳态,此时,由于PF状态估计算法自身的跟踪能力可跟踪到系统的攻击状态导致无法检测出异常,从而使得该算法在检测持续性攻击时,存在较高的漏检率,这一不足也为工控系统安全带来威胁.因此,为了实现对持续性攻击的检测,降低PF 状态估计算法对该类攻击的漏检率,本文将工控系统内在特征与攻击特征相结合,提出基于PF输入估计的态势理解算法.该方法考虑了工控系统遭受到网络攻击时(以传感器参数篡改为例),虚假的传感器参数导致系统的输入值与输出值之间的非线性关系发生变化,利用这一特点,结合Monte-Carlo思想,对系统输入的先验概率进行随机取样,依据相似性对样本粒子分配权值,并获取系统输入的估计值将估计值与实际值之间的差值,作为系统态势特征,判断工控系统是否处于危险态势,避免了由于PF状态估计引起的漏检,为针对工控系统网络的持续性攻击检测提出新思路.在本文最后,对经典PF 状态估计算法和态势理解算法进行仿真验证.需要说明,不同于文献[12]对网络安全态势预测算法的精度进行考察(算法精度越高,对复杂网络环境的预测结果越准确),本文考虑到工控系统遭受攻击的后果严重性,系统中出现的漏报与误报将会误导操作员对工控系统的态势判断,从而引发灾难,因此参考Salerno等[13]提出的态势指标,对本文提出算法报警结果的漏检率与错误率进行分析,而不再考虑算法精度.实验结果表明,本文提出的算法能有效感知系统中的不同态势(正常态势及危险态势),漏检率与错误率均处于较低水平.1工控网络态势感知模型1.1网络安全态势感知模型简介Endsley[14]在1988年提出了态势感知的定义:在一定的时空条件下,对环境因素的获取、理解以及对未来状态的预测.网络安全态势感知(Network security situation awareness,NSSA)模型分为三个层次,通过对来自系统的数据进行处理后,获取系统当前态势,并对未来态势进行预测.从下至上依次为(如图1所示):1)态势要素获取:态势要素获取层是NSSA模型的基础,主要包括对数据的预处理和特征提取.其目的主要在于对工控系统中的海量数据进行缩减,保留关键信息,并从中提取特征.2)态势理解:对获取的特征进行进一步处理,包括数据关联、特征检测、识别与分类,并对多个分类结果进行决策融合,获取最终决策即整体系统态势.3)态势预测:利用预测算法对工控网络态势的趋势进行预测.1.2工控网络态势出于保护工控系统安全的目的,将工控网络态势分为安全态势和危险态势[15].安全态势指系统中的过程参数均处于系统既定的安全值范围内;危险态势指系统遭受到攻击,过程参数超出安全临界值δ的工控系统状态.图1态势感知模型Fig.1Situation awareness model8期陆耿虹等:基于粒子滤波的工业控制网络态势感知建模1407一般的PLC系统如图2所示,传感器在将传感数据发送至PLC 的过程中,可能会遭受到攻击者的攻击,真实传感数据被篡改[16],导致控制系统不稳定.本文假定系统的危险态势是由攻击者施加的假数据注入攻击[17]产生.图2PLC 系统示意图Fig.2A diagram of PLC implementationy (t )=y (t )+α(t ),t ∈T atc (1)其中,y (t )和 y (t )分别是在安全态势和危险态势下,PLC 接收到的数值.α(t )为攻击者施加的攻击参数,T atc =[t atc s ,t atc e ]为从攻击开始t atc s 到攻击结束t atc e 的攻击时间.1.3工控网络态势感知建模态势理解层作为态势感知过程中承下启上的中心环节,利用态势要素对获取的数据进行态势理解,并将数据处理结果输送至态势预测层.态势理解的优劣,将直接影响态势感知的结果以及态势预测的性能.因此高效准确的态势理解过程在态势感知中,显得尤为重要.本文创新性地提出了工控网络态势感知模型,如图3所示,该模型从下至上共包含三个部分:态势要素获取层、态势理解层以及后续态势感知过程,本文主要对底部两层进行研究与分析.1)态势要素获取层:采集来自各传感器节点的数据,将其存储在数据集D 中.2)态势理解层:利用PF 算法估计系统输出,并提取特征,使用态势指标对要素理解的效果进行衡量,最后将态势理解结果输出至态势评估与预测中.图3工控网络态势感知模型Fig.3Industrial control network situationawareness model定义1.数据集合D i0:k ={d j ,j =0,···,k }表示从0∼k 时刻,第i 个节点采集的数据集合.定义2.特征提取E 作为PF 输入估计的结果之一,记录PF 输入估计算法的输出结果,是数据集D i 0:k 在经PF 输入估计算法处理后,得到的特征序列.E ={e i atc |i =1,···,m }(2)定义3.态势指标M ={MR,F R }包含两个元素.表示在进行PF 状态估计时出现的错误率和漏检率.MR =kj =1I (m j )k j =1S (m j )(3)F R =1−kj =1C (m j )k j =1W (m j )(4)其中,I 为误测特征个数,S 为测得特征个数,C 为正确测得的危险态势特征个数,W 为期望得到的危险态势特征个数.1408自动化学报44卷由于在特征提取过程中,可能存在感知错误、遗漏等情况,因此提出对态势特征获取过程中PF出现的错误特征数量和丢失的特征数量进行衡量.本文提出的态势感知模型中的态势理解层不仅能对来自工控系统众多节点的海量数据进行简化,给出系统态势特征,而且可以利用态势指标对态势理解过程的质量进行计算,为后续阶段的态势感知结果可靠性提供依据.1.3.1粒子滤波状态估计为了获取非线性、非高斯噪声的工控系统状态特征,采用PF算法进行状态估计,是一种很有效的非线性滤波技术[18],适用于任何能用状态空间模型表示的非高斯背景的非线性随机系统,精度可以逼近最优估计.该算法的实质是由粒子及其权重组成的离散随机测度近似相关的概率分布,并根据算法递推更新离散随机测度[19].对于一个非线性、非高斯过程建模如下:x k=g(x k−1,w k)(5)y k=h(x k,v k)(6)其中,x k为待估计的状态量,假设状态x k的先验分布p(x0)已知;y k为已知的观测量;g(·)为状态转移方程,h(·)为观测方程;w k和v k都为独立的噪声,分别称为状态噪声和观测噪声.步骤1.初始化.设k=0,采样:x i∼p(x0),根据p(x0)分布采样得到N个x i0,i=1,2,···,N.步骤2.重要性权值计算.采样x ik∼q(x k|x i0:k−1,y0:k),i=1,2,···,N,利用下式计算重要性权值.w ik =w ik−1p(y k|x ik−1)=w ik−1p(y k|x ik)p(x k|x ik−1)q(x k|x i0:k−1,y k)(7)其中,p(y k|x i k)为似然函数概率密度.p(y k|x ik )=p ek(y k−h(x ik))(8)式(7)中的q(x k|x i0:k−1,y k)是重要性概率密度,在本算法中,选取使权系数方差最小的最优重要密度函数.q(x k|x i0:k−1,y k)=p(x k|x ik−1)(9)在计算重要性权值后,进行归一化.¯w i k =w ikNi=1w ik(10)步骤3.重采样.设定有效样本数N threshold,并计算退化因子N effN eff=1Ni=1(¯w ik)2(11)N eff越小,意味着退化现象越严重.若N eff<N threshold,则进行重采样,将原来的带权样本{x i0:k,¯w i k}N i=1映射为等权样本{˜x i0:k,1/N}Ni=1.其中,˜x i0:k为重采样后的粒子.步骤4.预测.获取状态预测ˆx k,据此计算观测值估计ˆy k,并计算估计值与真实值的偏差e k(特征).ˆx k=Ni=1¯w ik˜x ik(12)ˆy k=h(ˆx k,v k)(13)e k=y k−ˆy k(14)步骤5.输出.将e k与安全阈值δ进行比较,当|e k|>δ时,记录系统第i次出现危险态势的时刻k iatc以及对应偏差e i k.1.3.2基于粒子滤波输入估计的态势理解算法在实际应用PF状态估计对系统受到的攻击进行检测时,实验结果显示,对于系统中施加持续时间为100小时的攻击,PF状态估计算法可以在系统被攻击(即状态值发生突然变化)后的10分钟内检测到攻击,即偏差值e将会超出阈值;但是由于PF估计算法自身具备的状态变化跟踪能力,在系统遭受到攻击的2小时后,系统状态将趋于稳定,即此时的偏差值e将会接近于零,从而导致PF状态估计算法无法持续检测出系统受到的攻击.考虑到对于输入输出之间存在函数关系y=f(u)的系统,在遭受到攻击时,系统的输入u也会发生变化,因此,本文提出基于PF输入估计的态势感知算法,以实现对长时间持续攻击的态势感知,降低系统漏报率.基于PF输入估计的态势感知算法,不再考虑状态的估计,利用输出残差进行报警;而是利用Monte-Carlo思想,在已获得的输出y k基础上,估计输入ˆu.利用实际输入(控制器输出)u与ˆu的差值,对系统态势进行感知.算法1.基于PF输入估计的态势感知算法步骤1.获取t=0,···,k时刻的输出y k;步骤2.初始化.设k=0,在[u min,u max]内随机采样N次,获得N个随机样本(粒子),构成序列{u∗k(i)|i=1,···,N};8期陆耿虹等:基于粒子滤波的工业控制网络态势感知建模1409步骤3.权值分配.对每个粒子u∗k(i)分配相应的权重q∗k(i),i=1,···,N,计算方式如下:q∗k (i)=p(y k|u∗k(i))Nj=1p(y k|u∗k(j))(15)其中,p(y k|u∗k(i))为相似性,即p(y k|u∗k (i))=p e∗k(y k−f(u∗k(i)))(16)步骤4.重采样.采用多项式重采样法,将原来的带权样本{u∗0:k(i),q∗k(i)}N i=1映射为等权样本{˜u∗0:k ,1/N}Ni=1.其中,˜u∗0:k(i)为重采样后的粒子,获得新粒子样本.步骤5.输出估计.获取输出估计值预测ˆu k,并计算估计值与真实值的偏差e∗k(特征).ˆu k=Ni=1q∗k(i)˜u∗k(i)(17)e∗k=u k−ˆu k(18)步骤6.计算态势特征.将e∗k与安全阈值δ进行比较,当|e∗k|>δ时,记录系统第j次出现危险态势的时刻k∗atc(j)以及对应偏差e∗k(j).步骤7.计算态势指标.利用式(3)和式(4)计算该系统的态势指标,态势指标M={MR,F R}.步骤8.态势理解结果输出.依据步骤6和步骤7的计算结果,整理得到态势理解结果并作为算法输出E,M.2实验验证2.1仿真对象某精馏塔提馏段温度单回路控制方案[20]如图4所示,蒸馏塔提馏段某块板的温度为主变量,控制器TC21通过控制信号u控制蒸汽控制阀对温度进行控制,温度传感器TT21能对提馏段的温度y进行检测(系统输出),y sp为设定值.2.2仿真过程对PF状态估计算法和态势理解算法进行仿真,通过计算两种算法的漏报率,对算法有效性进行分析.阶段1.仿真模型建立.依据图4的控制方案,建立相应的控制系统方框图,如图5所示.对图5中各环节进行参数设置:G T m为温度测量环节,G T m =1/(s+1);控制阀G v为近似线性阀,G v=1;蒸汽流量对象G p2=0.1/(1.5s+1);提馏段温度对象的控制通道与扰动通道动态特性的参数设置分别为G p1=5/(4s2+5s+1),G d=−0.5/(3s+1);单回路控制器TC的PID参数K c=2.4,T i=8.8, T d=2.2.图4提馏段温度单回路控制方案Fig.4Temperature single loop controlscheme ofdistillation图5提馏段温度单回路控制系统方框图Fig.5Block diagram of temperature single loop controlscheme of distillation阶段2.态势设置.对安全态势及遭受不同时长攻击的两种危险态势进行仿真,设定系统运行总时长T run=500.1)安全态势:系统正常运行,温度设定值y sp= 20;2)危险态势1:在k1=200和k2=300时刻,攻击者篡改温度传感器值,分别施加攻击强度为α(k1)=30,α(k2)=−30的攻击,每次攻击持续时长为T atc=5;3)危险态势2:在k=200时,攻击者开始篡改温度传感器值,攻击强度为:α(k)=30,攻击持续时长为T atc=100.图6为系统中可能出现的三种态势仿真结果示意图.阶段3.算法验证.算法验证部分选择t=70以后的数据进行分析,即对系统处于稳定后的数据进行仿真处理.1)PF状态估计.图7为利用PF状态估计对三种情况进行态势检测的结果,假设安全阈值δ=2.1410自动化学报44卷图6三种不同态势情况Fig.6The three differentsituations图7PF 状态估计算法仿真结果Fig.7The simulation results related to PF stateestimation algorithm从图7可以看出,a)M a ={0,0},此时算法没有检测到攻击,判断系统处于正常运行状态;b)M b ={0.0200,0.1667},此时算法检测到两次攻击,存在较低的错误率与漏检率;c)M c ={0.2040,0.9604},由态势指标可得,该算法在面对持续时间较长的攻击时,漏检率高达0.9604.但是能检测到攻击开始以及结束的时刻.2)基于PF 输入估计的态势理解.图8为利用态势理解算法对三种情况进行态势检测的结果,假设安全阈值δ=5.从图8可以看出,a)M a ={0,0},此时算法没有检测到攻击,判断系统处于正常运行状态;b)M b ={0.0820,0.1667},此时算法检测到两次攻击,错误率与漏检率均较低;c)M c ={0.048,0.0396};检测到长持续时间下的攻击,错误率与漏检率均低于5%.图8态势理解算法仿真结果Fig.8The simulation results related to situationawareness algorithm2.3仿真结果分析对比两种算法的仿真结果可知:1)PF 状态估计算法由a)和b)的检测结果可知,当系统存在突然发生的变化时,该算法能进行有效的检测,特征值变8期陆耿虹等:基于粒子滤波的工业控制网络态势感知建模1411化明显,检测的错误率与漏检率较低;由c)的仿真结果可知,该算法无法感知到系统中出现的长持续性攻击,存在很高的漏报率,对系统安全产生严重威胁.2)基于PF输入估计的态势理解算法a)和b)的仿真结果证明,该算法能有效跟踪和预测输入的变化趋势,两种算法的漏检率相同,尽管态势理解算法的错误率相对PF状态估计算法偏高6%,但是对于系统安全性能而言,该算法依然有效检测出了b)的危险态势;由c)的仿真结果可得,态势理解算法能有效检测到系统中存在的长时间持续的攻击,错误率与漏检率均小于5%,远低于PF状态估计算法.对比仿真结果可知,本文提出的基于PF输入估计的态势理解算法能有效判断系统中出现的危险态势,为工控网络安全态势感知提供可靠的感知判据.3结论本文介绍了基于粒子滤波的工业控制网络态势感知建模,将文中构造的态势感知模型中的态势理解层作为研究重点,提出了基于PF输入估计的态势理解算法.该算法是对经典PF状态估计的改进,在Monte-Carlo思想的基础上,考虑到系统输入与输出之间的联系,通过输出值校准输入的估计值,利用实际值与估计值之间存在的差值,判断系统是处于安全态势还是危险态势.该算法具有较好的输入值估计能力,可准确获取系统态势特征,给出态势指标,对特征的可靠性进行定量衡量.该算法可为后续的态势预测过程提供科学可靠的数据信息,提升态势感知结果的准确性.实验结果表明,本文提出的态势理解算法,能有效地利用数据源中的信息对系统内存在的危险态势进行感知.仿真结果表明该算法具有较高的可靠性与准确性.References1Huang Jia-Hui,Feng Dong-Qin,Wang Hong-Jian.A method for quantifying vulnerability of industrial control system based on attack graph.Acta Automatica Sinica,2016, 42(5):792−798(黄家辉,冯冬芹,王虹鉴.基于攻击图的工控系统脆弱性量化方法.自动化学报,2016,42(5):792−798)2Genge B,Nai Fovino I,Siaterlis C,Masera M.Analyzing cyber-physical attacks on networked industrial control sys-tems.Critical Infrastructure Protection V.Berlin Heidel-berg,Germany:Springer,2011.167−1833Lu J,Yang X W,Zhang G Q.Support vector machine-based multi-source multi-attribute information integration for situation assessment.Expert Systems with Applications, 2008,34(2):1333−13404Bass T.Multisensor data fusion for next generation dis-tributed intrusion detection systems.In:Proceedings of the 1999IRIS National Symposium on Sensor and Data Fusion.Washington,USA:IRIS,1999.24−275Naderpour M,Lu J,Zhang G Q.An abnormal situation modeling method to assist operators in safety-critical sys-tems.Reliability Engineering and System Safety,2015,133: 33−476Kim M C,Seong P H.An analytic model for situation as-sessment of nuclear power plant operators based on Bayesian inference.Reliability Engineering and System Safety,2006, 91(3):270−2827Jia Chi-Qian,Feng Dong-Qin.Industrial control system de-vices security assessment with multi-objective decision.Acta Automatica Sinica,2016,42(5):706−714(贾驰千,冯冬芹.基于多目标决策的工控系统设备安全评估方法研究.自动化学报,2016,42(5):706−714)8Doucet A,de Freitas N,Gordon N.Sequential Monte Carlo Methods in Practice.New York,USA:Springer,2001.9Carpenter J,Clifford P,Fearnhead P.Improved particlefil-ter for nonlinear problems.IEE Proceedings—Radar,Sonar and Navigation,1999,146(1):2−710Kadirkamanathan V,Li P,Jaward M H,Fabri S G.Particle filtering-based fault detection in non-linear stochastic sys-tems.International Journal of Systems Science,2002,33(4): 259−26511Arulampalam S,Maskell S,Gordon N,Clapp T.A tu-torial on particlefilters for online nonlinear/non-Gaussian Bayesian tracking.IEEE Transactions on Signal Processing, 2002,50(2):174−18812Tang Yong-Li,Li Wei-Jie,Yu Jin-Xia,Yan Xi-Xi.Re-search on a prediction method of network security situation based on particlefiputer Applications and Soft-ware,2017,34(1):293−297(汤永利,李伟杰,于金霞,闫玺玺.基于粒子滤波的网络安全态势预测方法研究.计算机应用与软件,2017,34(1):293−297)13Salerno J J,Blasch E P,Hinman M,Boulware D M.Evalu-ating algorithmic techniques in supporting situation aware-ness.In:Proceedings of the2005Multisensor,Multisource Information Fusion:Architectures,Algorithms,and Appli-cations.Orlando,Florida,USA:SPIE,2005.96−10414Endsley M R.Design and evaluation for situation awareness enhancement.In:Proceedings of the32nd Human Factors Society Annual Meeting.Santa Monica,USA:SAGE,1988.97−10115Naderpour M,Lu J,Zhang G Q.A situation risk awareness approach for process systems safety.Safety Science,2014, 64:173−1891412自动化学报44卷16Gonzalez C A,Hinton A.Detecting malicious software ex-ecution in programmable logic controllers using powerfin-gerprinting.Critical Infrastructure Protection VIII.Berlin Heidelberg,Germany:Springer,2014.15−2717Lu Geng-Hong,Feng Dong-Qin.Industrial control system network security situation awareness modeling and algo-rithm implementation.Control Theory and Applications, 2016,33(8):1054−1060(陆耿虹,冯冬芹.工控网络安全态势感知算法实现.控制理论与应用,2016,33(8):1054−1060)18Cheng Q,Varshney P K,Michels J,Belcastro C M.Dis-tributed fault detection via particlefiltering and decision fusion.In:Proceedings of the8th International Conference on Information Fusion.Philadelphia,PA,USA:IEEE,2005.1239−124619Li Tian-Cheng,Fan Hong-Qi,Sun Shu-Dong.Particlefilter-ing:theory,approach,and application for multitarget track-ing.Acta Automatica Sinica,2015,41(12):1981−2002(李天成,范红旗,孙树栋.粒子滤波理论、方法及其在多目标跟踪中的应用.自动化学报,2015,41(12):1981−2002)20Dai Lian-Kui,Yu Ling,Tian Xue-Min,Wang Shu-Qing.Process Control Engineering(3rd edition).Beijing:Chemi-cal Industry Press,2012.(戴连奎,于玲,田学民,王树青.过程控制工程(第3版).北京:化学工业出版社,2012.)陆耿虹浙江大学智能系统与控制研究所博士研究生.主要研究方向为工业控制系统网络安全态势感知.E-mail:****************.cn(LU Geng-Hong Ph.D.candidateat the Institute of Cyber-Systems andControl,Zhejiang University.Her re-search interest covers industrial control system network se-curity situation awareness.)冯冬芹浙江大学工业控制技术国家重点实验室和浙江大学智能系统与控制研究所教授.主要研究方向为现场总线,实时以太网,工业无线通信技术,工业控制系统安全以及网络控制系统的研发与标准化工作.本文通信作者.E-mail:*******************.cn (FENG Dong-Qin Professor at the State Key Labora-tory of Industrial Control Technology,Institute of Cyber-Systems and Control,Zhejiang University.His research interest coversfield bus,real-time ethernet,industrial wire-less communication technology,security of industrial con-trol system,and network control system.Corresponding author of this paper.)。
JVM for a Heterogeneous Shared Memory SystemDeQing Chen,Chunqiang Tang,Sandhya Dwarkadas,and Michael L.ScottComputer Science Department,University of Rochester AbstractInterWeave is a middleware system that supports the shar-ing of strongly typed data structures across heterogeneouslanguages and machine architectures.Java presents spe-cial challenges for InterWeave,including write detection,data translation,and the interface with the garbage col-lector.In this paper,we discuss our implementation ofJ-InterWeave,a JVM based on the Kaffe virtual machineand on our locally developed InterWeave client software.J-InterWeave uses bytecode instrumentation to detectwrites to shared objects,and leverages Kaffe’s class ob-jects to generate type information for correct transla-tion between the local object format and the machine-independent InterWeave wire format.Experiments in-dicate that our bytecode instrumentation imposes lessthan2%performance cost in Kaffe interpretation mode,and less than10%overhead in JIT mode.Moreover,J-InterWeave’s translation between local and wire format ismore than8times as fast as the implementation of ob-ject serialization in Sun JDK1.3.1for double arrays.Toillustrate theflexibility and efficiency of J-InterWeave inpractice,we discuss its use for remote visualization andsteering of a stellar dynamics simulation system writtenin C.1IntroductionMany recent projects have sought to support distributedshared memory in Java[3,16,24,32,38,41].Manyof these projects seek to enhance Java’s usefulness forlarge-scale parallel programs,and thus to compete withmore traditional languages such as C and Fortran in thearea of scientific computing.All assume that applicationcode will be written entirely in Java.Many—particularlythose based on existing software distributed shared mem-ory(S-DSM)systems—assume that all code will run oninstances of a common JVM.has yet to displace Fortran for scientific computing sug-gests that Java will be unlikely to do so soon.Even for systems written entirely in Java,it is appealing to be able to share objects across heterogeneous JVMs. This is possible,of course,using RMI and object serial-ization,but the resulting performance is poor[6].The ability to share state across different languages and heterogeneous platforms can also help build scalable dis-tributed services in general.Previous research on var-ious RPC(remote procedure call)systems[21,29]in-dicate that caching at the client side is an efficient way to improve service scalability.However,in those sys-tems,caching is mostly implemented in an ad-hoc man-ner,lacking a generalized translation semantics and co-herence model.Our on-going research project,InterWeave[9,37],aims to facilitate state sharing among distributed programs written in multiple languages(Java among them)and run-ning on heterogeneous machine architectures.InterWeave applications share strongly-typed data structures located in InterWeave segments.Data in a segment is defined using a machine and platform-independent interface de-scription language(IDL),and can be mapped into the ap-plication’s local memory assuming proper InterWeave li-brary calls.Once mapped,the data can be accessed as ordinary local objects.In this paper,we focus on the implementation of In-terWeave support in a Java Virtual Machine.We call our system J-InterWeave.The implementation is based on an existing implementation of InterWeave for C,and on the Kaffe virtual machine,version1.0.6[27].Our decision to implement InterWeave support directly in the JVM clearly reduces the generality of our work.A more portable approach would implement InterWeave support for segment management and wire-format trans-lation in Java libraries.This portability would come,how-ever,at what we consider an unacceptable price in perfor-mance.Because InterWeave employs a clearly defined internal wire format and communication protocol,it is at least possible in principle for support to be incorporated into other JVMs.We review related work in Java distributed shared state in Section2and provide a brief overview of the Inter-Weave system in Section3.A more detailed description is available elsewhere[8,37].Section4describes the J-InterWeave implementation.Section5presents the results of performance experiments,and describes the use of J-InterWeave for remote visualization and steering.Sec-tion6summarizes our results and suggests topics for fu-ture research.2Related WorkMany recent projects have sought to provide distributed data sharing in Java,either by building customized JVMs[2,3,24,38,41];by using pure Java implementa-tions(some of them with compiler support)[10,16,32]; or by using Java RMI[7,10,15,28].However,in all of these projects,sharing is limited to Java applications. To communicate with applications on heterogeneous plat-forms,today’s Java programmers can use network sock-ets,files,or RPC-like systems such as CORBA[39].What they lack is a general solution for distributed shared state. Breg and Polychronopoulos[6]have developed an al-ternative object serialization implementation in native code,which they show to be as much as eight times faster than the standard implementation.The direct compari-son between their results and ours is difficult.Our exper-iments suggest that J-Interweave is at least equally fast in the worst case scenario,in which an entire object is mod-ified.In cases where only part of an object is modified, InterWeave’s translation cost and communication band-width scale down proportionally,and can be expected to produce a significant performance advantage.Jaguar[40]modifies the JVM’s JIT(just-in-time com-piler)to map certain bytecode sequences directly to na-tive machine codes and shows that such bytecode rewrit-ing can improve the performance of object serialization. However the benefit is limited to certain types of objects and comes with an increasing price for accessing object fields.MOSS[12]facilitates the monitoring and steering of scientific applications with a CORBA-based distributed object system.InterWeave instead allows an application and its steerer to share their common state directly,and in-tegrates that sharing with the more tightly coupled sharing available in SMP clusters.Platform and language heterogeneity can be supported on virtual machine-based systems such as Sun JVM[23] and [25].The Common Language Run-time[20](CLR)under framework promises sup-port for multi-language application development.In com-parison to CLR,InterWeave’s goal is relatively modest: we map strongly typed state across languages.CLR seeks to map all high-level language features to a common type system and intermediate language,which in turn implies more semantic compromises for specific languages than are required with InterWeave.The transfer of abstract data structures wasfirst pro-posed by Herlihy and Liskov[17].Shasta[31]rewrites bi-nary code with instrumentation for access checks forfine-grained S-DSM.Midway[4]relies on compiler support to instrument writes to shared data items,much as we do in the J-InterWeave JVM.Various software shared memory systems[4,19,30]have been designed to explicitly asso-ciate synchronization operations with the shared data they protect in order to reduce coherence costs.Mermaid[42] and Agora[5]support data sharing across heterogeneous platforms,but only for restricted data types.3InterWeave OverviewIn this section,we provide a brief introduction to the design and implementation of InterWeave.A more de-tailed description can be found in an earlier paper[8]. For programs written in C,InterWeave is currently avail-able on a variety of Unix platforms and on Windows NT. J-InterWeave is a compatible implementation of the In-terWeave programming model,built on the Kaffe JVM. J-InterWeave allows a Java program to share data across heterogeneous architectures,and with programs in C and Fortran.The InterWeave programming model assumes a dis-tributed collection of servers and clients.Servers maintain persistent copies of InterWeave segments,and coordinate sharing of those segments by clients.To avail themselves of this support,clients must be linked with a special In-terWeave library,which serves to map a cached copy of needed segments into local memory.The servers are the same regardless of the programming language used by clients,but the client libraries may be different for differ-ent programming languages.In this paper we will focus on the client side.In the subsections below we describe the application programming interface for InterWeave programs written in Java.3.1Data Allocation and AddressingThe unit of sharing in InterWeave is a self-descriptive data segment within which programs allocate strongly typed blocks of memory.A block is a contiguous section of memory allocated in a segment.Every segment is specified by an Internet URL and managed by an InterWeave server running at the host indi-cated in the URL.Different segments may be managed by different servers.The blocks within a segment are num-bered and optionally named.By concatenating the seg-ment URL with a block number/name and offset(delim-ited by pound signs),we obtain a machine-independent pointer(MIP):“/path#block#offset”. To create and initialize a segment in Java,one can ex-ecute the following calls,each of which is elaborated on below or in the following subsections:IWSegment seg=new IWSegment(url);seg.wl_acquire();MyType myobj=new MyType(seg,blkname);myobj.field=......seg.wl_release();In Java,an InterWeave segment is captured as an IWSegment object.Assuming appropriate access rights, the new operation of the IWSegment object communi-cates with the appropriate server to initialize an empty segment.Blocks are allocated and modified after acquir-ing a write lock on the segment,described in more detail in Section3.3.The IWSegment object returned can be passed to the constructor of a particular block class to al-locate a block of that particular type in the segment. Once a segment is initialized,a process can convert be-tween the MIP of a particular data item in the segment and its local pointer by using mip ptr and ptr mip where appropriate.It should be emphasized that mip ptr is primar-ily a bootstrapping mechanism.Once a process has one pointer into a data structure(e.g.the root pointer in a lat-tice structure),any data reachable from that pointer can be directly accessed in the same way as local data,even if embedded pointers refer to data in other segments.In-terWeave’s pointer-swizzling and data-conversion mech-anisms ensure that such pointers will be valid local ma-chine addresses or references.It remains the program-mer’s responsibility to ensure that segments are accessed only under the protection of reader-writer locks.3.2HeterogeneityTo accommodate a variety of machine architectures,In-terWeave requires the programmer to use a language-and machine-independent notation(specifically,Sun’s XDR[36])to describe the data types inside an InterWeave segment.The InterWeave XDR compiler then translates this notation into type declarations and descriptors appro-priate to a particular programming language.When pro-gramming in C,the InterWeave XDR compiler generates twofiles:a.hfile containing type declarations and a.c file containing type descriptors.For Java,we generate a set of Java class declarationfiles.The type declarations generated by the XDR compiler are used by the programmer when writing the application. The type descriptors allow the InterWeave library to un-derstand the structure of types and to translate correctly between local and wire-format representations.The lo-cal representation is whatever the compiler normally em-ploys.In C,it takes the form of a pre-initialized data struc-ture;in Java,it is a class object.3.2.1Type Descriptors for JavaA special challenge in implementing Java for InterWeave is that the InterWeave XDR compiler needs to gener-ate correct type descriptors and ensure a one-to-one cor-respondence between the generated Java classes and C structures.In many cases mappings are straight forward: an XDR struct is mapped to a class in Java and a struct in C,primitivefields to primitivefields both in Java andC,pointersfields to object references in Java and pointers in C,and primitive arrays to primitive arrays. However,certain“semantics gaps”between Java and C force us to make some compromises.For example,a C pointer can point to any place inside a data block;while Java prohibits such liberties for any object reference. Thus,in our current design,we make the following compromises:An InterWeave block of a single primitive data item is translated into the corresponding wrapped class for the primitive type in Java(such as Integer,Float, etc.).Embedded structfields in an XDR struct definition areflattened out in Java and mapped asfields in its parent class.In C,they are translated naturally into embeddedfields.Array types are mapped into a wrapped IWObject(including the IWacquire,wl acquire, and rlpublic class IWSegment{public IWSegment(String URL,Boolean iscreate);public native staticint RegisterClass(Class type);public native staticObject mip_to_ptr(String mip);public native staticString ptr_to_mip(IWObject Ob-ject obj);......public native int wl_acquire();public native int wl_release();public native int rl_acquire();public native int rl_release();......}Figure2:IWSegment Class4.1.1JNI Library for IWSegment ClassThe native library for the IWSegment class serves as an intermediary between Kaffe and the C InterWeave library. Programmer-visible objects that reside within the IWSeg-ment library are managed in such a way that they look like ordinary Java objects.As in any JNI implementation,each native method has a corresponding C function that implements its function-ality.Most of these C functions simply translate their pa-rameters into C format and call corresponding functions in the C InterWeave API.However,the creation of an In-terWeave object and the method RegisterClass need special explanation.Mapping Blocks to Java Objects Like ordinary Java objects,InterWeave objects in Java are created by“new”operators.In Kaffe,the“new”operator is implemented directly by the bytecode execution engine.We modi-fied this implementation to call an internal function new-Block in the JNI library and newBlock calls the Inter-Weave C library to allocate an InterWeave block from the segment heap instead of the Kaffe object heap.Before returning the allocated block back to the“new”operator, newBlock initializes the block to be manipulated cor-rectly by Kaffe.In Kaffe,each Java object allocated from the Kaffe heap has an object header.This header contains a pointer to the object class and a pointer to its own monitor.Since C InterWeave already assumes that every block has a header (it makes no assumption about the contiguity of separate blocks),we put the Kaffe header at the beginning of what C InterWeave considers the body of the block.A correctly initialized J-InterWeave object is shown in Figure3.Figure3:Block structure in J-InterWeaveAfter returning from newBlock,the Kaffe engine calls the class constructor and executes any user cus-tomized operations.Java Class to C Type Descriptor Before any use of a class in a J-InterWeave segment,including the creation of an InterWeave object of the type,the class object must befirst registered with RegisterClass.Register-Class uses the reflection mechanism provided by the Java runtime system to determine the following informa-tion needed to generate the C type descriptor and passes it to the registration function in the C library.1.type of the block,whether it is a structure,array orpointer.2.total size of the block.3.for structures,the number offields,eachfield’s off-set in the structure,and a pointer to eachfield’s type descriptor.4.for arrays,the number of elements and a pointer tothe element’s type descriptor.5.for pointers,a type descriptor for the pointed-to data.The registered class objects and their corresponding C type descriptors are placed in a hashtable.The new-Block later uses this hashtable to convert a class object into the C type descriptor.The type descriptor is required by the C library to allocate an InterWeave block so that it has the information to translate back and forth between local and wire format(see Section3).4.2KaffeJ-InterWeave requires modifications to the byte code in-terpreter and the JIT compiler to implementfine-grained write detection via instrumentation.It also requires changes to the garbage collector to ensure that InterWeave blocks are not accidentally collected.Figure4:Extended Kaffe object header forfine-grained write detection4.2.1Write DetectionTo support diff-based transmission of InterWeave segment updates,we must identify changes made to InterWeave objects over a given span of time.The current C ver-sion of InterWeave,like most S-DSM systems,uses vir-tual memory traps to identify modified pages,for which it creates pristine copies(twins)that can be compared with the working copy later in order to create a diff.J-InterWeave could use this same technique,but only on machines that implement virtual memory.To enable our code to run on handheld and embedded devices,we pursue an alternative approach,in which we instrument the interpretation of store bytecodes in the JVM and JIT. In our implementation,only writes to InterWeave block objects need be monitored.In each Kaffe header,there is a pointer to the object method dispatch table.On most architectures,pointers are aligned on a word boundary so that the least significant bit is always zero.Thus,we use this bit as theflag for InterWeave objects.We also place two32-bit words just before the Kaffe object header,as shown in Figure4.The second word—modification status—records which parts of the object have been modified.A block’s body is logically divided into32parts,each of which corresponds to one bit in the modification status word.Thefirst extended word is pre-computed when initializing an object.It is the shift value used by the instrumented store bytecode code to quickly determine which bit in the modification status word to set(in other words,the granularity of the write detection).These two words are only needed for In-terWeave blocks,and cause no extra overhead for normal Kaffe objects.4.2.2Garbage CollectionLike distributedfile systems and databases(and unlike systems such as PerDiS[13])InterWeave requires man-ual deletion of data;there is no garbage collection.More-over the semantics of InterWeave segments ensure that an object reference(pointer)in an InterWeave object(block) can never point to a non-InterWeave object.As a result, InterWeave objects should never prevent the collection of unreachable Java objects.To prevent Kaffe from acci-dentally collecting InterWeave memory,we modify the garbage collector to traverse only the Kaffe heap.4.3InterWeave C libraryThe InterWeave C library needs little in the way of changes to be used by J-InterWeave.When an existing segment is mapped into local memory and its blocks are translated from wire format to local format,the library must call functions in the IWSegment native library to initialize the Kaffe object header for each block.When generating a description of modified data in the write lock release operation,the library must inspect the modifi-cation bits in Kaffe headers,rather than creating diffs from the pristine and working copies of the segment’s pages.4.4DiscussionAs Java is supposed to be“Write Once,Run Anywhere”, our design choice of implementing InterWeave support at the virtual machine level can pose the concern of the portability of Java InterWeave applications.Our current implementation requires direct JVM support for the fol-lowing requirements:1.Mapping from InterWeave type descriptors to Javaobject classes.2.Managing local segments and the translation be-tween InterWeave wire format and local Java objects.3.Supporting efficient write detection for objects in In-terWeave segments.We can use class reflection mechanisms along with pure Java libraries for InterWeave memory management and wire-format translation to meet thefirst two require-ments and implement J-InterWeave totally in pure Java. Write detection could be solved using bytecode rewrit-ing techniques as reported in BIT[22],but the resulting system would most likely incur significantly higher over-heads than our current implementation.We didn’t do this mainly because we wanted to leverage the existing C ver-sion of the code and pursue better performance.In J-InterWeave,accesses to mapped InterWeave blocks(objects)by different Java threads on a single VM need to be correctly synchronized via Java object monitors and appropriate InterWeave locks.Since J-InterWeave is not an S-DSM system for Java virtual machines,the Java memory model(JMM)[26]poses no particular problems. 5Performance EvaluationIn this section,we present performance results for the J-InterWeave implementation.All experiments employ a J-InterWeave client running on a1.7GHz Pentium-4Linux machine with768MB of RAM.In experiments involving20406080100120_201_co mp r e s s _202_j e s s _205_ra y t r a c e _209_db _213_j a va c _222_m p e g a u d i o _227_m t r t _228_j a c kJVM98 BenchmarksT i m e (s e c .)Figure 5:Overhead of write-detect instrumentation in Kaffe’s interpreter mode01234567_201_c o mp r e s s _202_j e s s _205_r a y t r a c e _209_d b _213_j a v a c _222_m p e g a u d i o _227_m t r t _228_j a c k JVM98 Benchmarks T i m e (s e c .)Figure 6:Overhead of write-detect instrumentation inKaffe’s JIT3modedata sharing,the InterWeave segment server is running on a 400MHz Sun Ultra-5workstation.5.1Cost of write detectionWe have used SPEC JVM98[33]to quantify the perfor-mance overhead of write detection via bytecode instru-mentation.Specifically,we compare the performance of benchmarks from JVM98(medium configuration)run-ning on top of the unmodified Kaffe system to the per-formance obtained when all objects are treated as if they resided in an InterWeave segment.The results appear in Figures 5and 6.Overall,the performance loss is small.In Kaffe’s inter-preter mode there is less than 2%performance degrada-tion;in JIT3mode,the performance loss is about 9.1%.The difference can be explained by the fact that in inter-preter mode,the per-bytecode execution time is already quite high,so extra checking time has much less impact than it does in JIT3mode.The Kaffe JIT3compiler does not incorporate more re-cent and sophisticated technologies to optimize the gener-ated code,such as those employed in IBM Jalepeno [35]and Jackal [38]to eliminate redundant object referenceand array boundary checks.By applying similar tech-niques in J-InterWeave to eliminate redundant instrumen-tation,we believe that the overhead could be further re-duced.5.2Translation costAs described in Sections 3,a J-InterWeave application must acquire a lock on a segment before reading or writ-ing it.The acquire operation will,if necessary,ob-tain a new version of the segment from the InterWeaveserver,and translate it from wire format into local Kaffeobject format.Similarly,after modifying an InterWeavesegment,a J-InterWeave application must invoke a write lock release operation,which translates modified por-tions of objects into wire format and sends the changes back to the server.From a high level point of view this translation re-sembles object serialization ,widely used to create per-sistent copies of objects,and to exchange objects between Java applications on heterogeneous machines.In this sub-section,we compare the performance of J-InterWeave’stranslation mechanism to that of object serialization in Sun’s JDK v.1.3.1.We compare against the Sun im-plementation because it is significantly faster than Kaffe v.1.0.6,and because Kaffe was unable to successfully se-rialize large arrays in our experiments.We first compare the cost of translating a large array of primitive double variables in both systems.Under Sun JDK we create a Java program to serialize double arrays into byte arrays and to de-serialize the byte arrays backagain.We measure the time for the serialization and de-serialization.Under J-InterWeave we create a programthat allocates double arrays of the same size,releases (un-maps)the segment,and exits.We measure the releasetime and subtract the time spent on communication with the server.We then run a program that acquires (maps)the segment,and measure the time to translate the byte arrays back into doubles in Kaffe.Results are shown in Figure 7,for arrays ranging in size from 25000to 250000elements.Overall,J-InterWeave is about twenty-three times faster than JDK 1.3.1in serialization,and 8times faster in dese-rialization.5.3Bandwidth reduction To evaluate the impact of InterWeave’s diff-based wire format,which transmits an encoding of only those bytes that have changed since the previous communication,we modify the previous experiment to modify between 10and 100%of a 200,000element double array.Results appear in Figures 8and 9.The former indicates translation time,the latter bytes transmitted.20406080100120140250005000075000100000125000150000175000200000225000250000Size of double array (in elements)T i m e (m s e c .)Figure 7:Comparison of double array translation betweenSun JDK 1.3.1and J-InterWeave102030405060708090100100908070605040302010Percentage of changesT i m e (m s e c .)Figure 8:Time needed to translate a partly modified dou-ble arrayIt is clear from the graph that as we reduce the per-centage of the array that is modified,both the translationtime and the required communication bandwidth go down by linear amounts.By comparison,object serialization is oblivious to the fraction of the data that has changed.5.4J-InterWeave Applications In this section,we describe the Astroflow application,developed by colleagues in the department of Physics andAstronomy,and modified by our group to take advan-tage of InterWeave’s ability to share data across hetero-geneous platforms.Other applications completed or cur-rently in development include interactive and incremental data mining,a distributed calendar system,and a multi-player game.Due to space limitations,we do not present these here.The Astroflow [11][14]application is a visualization tool for a hydrodynamics simulation actively used in the astrophysics domain.It is written in Java,but employs data from a series of binary files that are generated sepa-rately by a computational fluid dynamics simulation sys-00.20.40.60.811.21.41.61.8100908070605040302010Percentage of changesT r a n s mi s s i o n s i z e (M B )Figure 9:Bandwidth needed to transmit a partly modified double array2040608010012014012416Number of CPUsT i m e (s e c .)Figure 10:Simulator performance using InterWeave in-stead of file I/Otem.The simulator,in our case,is written in C,and runs on a cluster of 4AlphaServer 41005/600nodes under the Cashmere [34]S-DSM system.(Cashmere is a two-level system,exploiting hardware shared memory within SMP nodes and software shared memory among nodes.InterWeave provides a third level of sharing,based on dis-tributed versioned segments.We elaborate on this three-level structure in previous papers [8].)J-InterWeave makes it easy to connect the Astroflow vi-sualization front end directly to the simulator,to create an interactive system for visualization and steering.The ar-chitecture of the system is illustrated in Figure 1(page 1).Astroflow and the simulator share a segment with one header block specifying general configuration parameters and six arrays of doubles.The changes required to the two existing programs are small and limited.We wrote an XDR specification to describe the data structures we are sharing and replaced the original file operations with shared segment operations.No special care is re-quired to support multiple visualization clients or to con-trol the frequency of updates.While the simulation data。
F ortiGate ®-VM with VMware NSX-T™Automated, Advanced Security for VMware NSX-T Data Center EnvironmentsBy extending the FortiGate-VM native integration with the VMware NSX-T Data Center, Fortinet delivers advanced security for east-west and north-south traffic. This deep integration provides customers with the confidence to extend their virtualized infrastructure across multi-hypervisor environments, private, and public clouds with a unified security layer.Fortinet and VMware NSX-T deliver zero-trust security with advanced L7 protection and policy-based firewall controls. Automation is enabled through a built-in NSX-T fabric connector for dynamic updates between NSX Manager and FortiGate-VM.Highlights•Advanced (L7) threat protection integrated withVMware NSX-T Data Center environments in SDDCs as well as private and public clouds•Streamlined SecOps, with automation and orchestration via Fortinet Fabric Connectors •Single-pane-of-glass management through VMware NSX Manager,with full visibility in FortiManager •Wide array of licensing choices to fit any infrastructurerequirementData SheetFortiOS EverywhereFortiOS, Fortinet’s Advanced Operating SystemFortiOS enables the convergence of high performing networking and security across the Fortinet Security Fabric. Because it can be deployed anywhere, it delivers consistent and context-aware security posture across network, endpoint, and multi-cloud environments. FortiOS powers all FortiGate deployments whether a physical or virtual device, as a container, or as a cloud service. This universal deployment model enables the consolidation of many technologies and use cases into a simplified, single policy and management framework. Its organically built best-of-breed capabilities, unified operating system, and ultra-scalability allows organizations to protect all edges, simplify operations, and run their business without compromising performance or protection.FortiOS dramatically expands the Fortinet Security Fabric’s ability to deliver advanced AI/ML-powered services, inline advanced sandbox detection, integrated ZTNA enforcement, and more, provides protection across hybrid deployment models for hardware, software, and Software-as-a-Service with SASE.FortiOS expands visibility and control, ensures the consistent deployment and enforcement of security policies, and enables centralized management across large-scale networks with the following key attributes:•Interactive drill-down and topology viewers that display real-time status•On-click remediation that provides accurate and quick protection against threats and abuses •Unique threat score system correlates weighted threats with users to prioritize investigationsFortiConverter Migration ServiceFortiConverter Service provides hassle-free migration to help organizations transition from a wide range of legacy firewalls to FortiGate Next-Generation Firewalls quickly and easily. The service eliminates errors and redundancy by employing best practices with advanced methodologies and automated processes. Organizations can accelerate their network protection with the latest FortiOS technology.Intuitive easy to use view into the network andendpoint vulnerabilitiesVisibility with FOS Application SignaturesAvailable inCloudHostedVirtualApplianceContainerFortiGuard ServicesNetwork and File SecurityServices provide protection against network-based and file-based threats. This consists of Intrusion Prevention (IPS) which uses AI/M models to perform deep packet/SSL inspectionto detect and stop malicious content, and apply virtual patching when a new vulnerability is discovered. It also includes Anti-Malware for defense against known and unknown file-based threats. Anti-malware services span both antivirus and file sandboxing to provide multi-layered protection and are enhanced in real-time with threat intelligence from FortiGuard Labs. Application Control enhances security compliance and offers real-time application visibility. Web / DNS SecurityServices provide protection against web-based threats including DNS-based threats, malicious URLs (including even in emails), and botnet/command and control communications. DNS filtering provides full visibility into DNS traffic while blocking high-risk domains, and protects against DNS tunneling, DNS infiltration, C2 server ID and Domain Generation Algorithms (DGA). URL filtering leverages a database of 300M+ URLs to identify and block links to malicious sites and payloads. IP Reputation and anti-botnet services prevent botnet communications, and block DDoS attacks from known sources.SaaS and Data SecurityServices address numerous security use cases across application usage as well as overall data security. This consists of Data Leak Prevention (DLP) which ensures data visibility, management and protection (including blocking exfiltration) across networks, clouds, and users, while simplifying compliance and privacy implementations. Separately, our Inline Cloud Access Security Broker (CASB) service protects data in motion, at rest, and in the cloud.The service enforces major compliance standards and manages account, user and cloud application usage. Services also include capabilities designed to continually assess your infrastructure, validate that configurations are working effectively and secure, and generate awareness of risks and vulnerabilities that could impact business operations. This includes coverage across IoT devices for both IoT detection and IoT vulnerability correlation.Zero-Day Threat PreventionZero-day threat prevention entails Fortinet’s AI-based inline malware prevention, our most advanced sandbox service, to analyze and block unknown files in real-time, offering sub-second protection against zero-day and sophisticated threats across all NGFWs. The service also has a built-in MITRE ATT&CK® matrix to accelerate investigations. The service focuses on comprehensive defense by blocking unknown threats while streamlining incident response efforts and reducing security overhead.OT SecurityThe service provides OT detection, OT vulnerability correlation, virtual patching, OT signatures, and industry-specific protocol decoders for overall robust defense of OT environments and devices.Secure Any Edge at Any ScaleAdvanced Virtual Security Processing Units (vSPUs)Virtual firewalls are commonly used to protect virtualized environments in software-defined data centers and multi-cloud environments on the basis that they are the least expensive and the most portable, enabling users to easily move a virtual firewall from cloud to cloud. One disadvantage of most virtual firewalls is that they deliver significantly lower network throughput as compared with physical firewalls, creating bottlenecks throughout the network and reducing business agility and performance.FortiGate virtual firewalls (FortiGate-VM), featuring advanced virtual security processing units (vSPUs), overcome the throughput barrier to provide top performance in private and public clouds. With FortiGate-VM, organizations can securely migrate any application and support a variety of use cases, including highly available large-scale virtual private networks (VPNs) in the cloud.”FortiGate-VM removes the cost-performance barriers to adopting virtual NGFWs, with several industry-leading features:•The FortiGate-VM vSPU is a unique technology that enhances performance by offloading part of packet processing to user space, while using a kernel bypass solution within the operating system. With vSPU enabled, FortiGate-VM can achieve more than triple the throughput for a UDP firewall rule.•Support for Intel QuickAssist Technology (Intel QAT), working on the latest QuickAssist Adapters, accelerates traffic processing through site-to-site IPSec VPNs. With QAT enabled, FortiGate-VM can achieve two to three times throughput improvements depending on the packet frame size.•Fortinet is the first NGFW vendor to support AWS C5n instances, which enables organizations to use a virtual firewall to secure compute-heavy applications in the cloud.FortiCare ServicesFortinet is dedicated to helping our customers succeed, and every year FortiCare Services help thousands of organizations get the most from our Fortinet Security Fabric solution. Our lifecycle portfolio offers Design, Deploy, Operate, Optimize, and Evolve services. Operate services offer device-level FortiCare Elite service with enhanced SLAs to meet our customer’s operational and availability needs. In addition, our customized account-level services provide rapid incident resolution and offer proactive care to maximize the security and performance of Fortinet deployments.DeploymentFigure 1: FortiGate-VM and FortiManager seamlessly integrate with VMware NSX Manager.VMware NSX Manager1. R eg ist er F or tiG at e-VM Ser vic e In se rti on(N or th-S ou th a nd/o r E as t-Wes t)3.De p lo yF o rt i Ga t e-V M(o rA PH AC l us t er f or No r th-So u th)2.L o ok f o r t he O V FF i l e5.P ol i c ys y nc4.D y n a mic O b je c tU p d a t e s• Service Registration—1, 2, 3• Ongoing Operation—4, 5orThe FortiGate-VM provides interoperability with NSX-T Data Center through service insertionas a third-party edge firewall (Figure 1).Core capabilities include:•By means of Fabric Connectors activated from the FortiManager console, FortiGate-VMintegrates with NSX-T Data Center to register both east-west and north-south serviceinsertions.•From that point on, security can be managed from the NSX-T dashboard and is automaticallycarried through to the FortiGate-VM instances running in the NSX-T Data Center.•Fortinet Fabric Connector automatically updates security policies associated with dynamicobjects in NSX-T whenever changes are made to underlying IP addresses, applicationmetadata, and annotations. This capability, which also extends to public cloud infrastructures(such as AWS, Azure, and GCP), relieves organizations of the need to manually updatesecurity policies, freeing up their time for other business-critical duties.CertificationsTechnical SpecificationsvCPU Support (Minimum / Maximum) 1 / 1 1 / 2 1 / 4Memory Support (Minimum)2 GB 2 GB 2 GB Storage Support (Minimum / Maximum)32 GB / 2 TB 32 GB / 2 TB 32 GB / 2 TB Wireless Access Points Controlled (Tunnel / Global)32 / 64512 / 1024512 / 1024Virtual Domains (Default / Maximum) *10 / 1010 / 2510 / 50Firewall Policies10 00010 00010 000Maximum Number of Registered Endpoints 200020008000Unlimited User LicenseYesYesYesTechnical SpecificationsvCPU Support (Minimum / Maximum) 1 / 8 1 / 16 1 / 32 1 / unlimitedMemory Support (Minimum)2 GB 2 GB 2 GB 2 GB Storage Support (Minimum / Maximum)32 GB / 2 TB 32 GB / 2 TB 32 GB / 2 TB 32 GB / 2 TB Wireless Access Points Controlled (Tunnel / Global)1024 / 40961024 / 40961024 / 40961024 / 4096Virtual Domains (Default / Maximum) *10 / 50010 / 50010 / 50010 / 500Firewall Policies200 000200 000200 000200 000Maximum Number of Registered Endpoints 20 00020 00020 00020 000Unlimited User License YesYesYesYesNetwork Interface SupportThe maximum number of network interfaces consumable by a FortiGate instance is 24 starting with FortiGate version 6.4.0. Prior versions allow 18. The minimum number is 1. The actualnumber of network interfaces attachable to instances varies depending on cloud platforms and instance types, and they may not allow you to attach the greater number of interfaces to an instance than their maximum limits even while FortiGate allows up to 24._________** FG-VMxxV and FG-VMxxS series do not come with a multi-VDOM feature by default. You can add it by applying separate VDOM addition perpetual licenses. See ORDER INFORMATION for VDOM SKUs. Special licenses for offline network environments are available for VMxxV series (01V to ULV), and they have the same specifications as those of VMxxV shown in the table above. For ordering offline licenses, please consult Fortinet sales representatives.3.1/3.27.0.67.0.5/7.2.13.0/3.16.4.36.4.4+Product Version Partner Product and VersionCertification DateListing URLFortiGate-VM 7.0.6NSX-T 3.1, 3.2, and 4.0Aug-22https:///comp_guide2/detail.php?deviceCategory=nsxt&productid=56054FortiGate-VM6.4.3NSX-T 2.5, 3.0, and 3.1Nov-20https:///resources/compatibility/detail.php?productid=51464&deviceCategory=nsxtSpecificationsOrdering InformationVirtual Domain License Add 15FG-VDOM-15-UG Upgrade license for adding 15 VDOMs to FortiOS 5.4 and later, limited by platform maximum VDOM capacity. Virtual Domain License Add 25FG-VDOM-25-UG Upgrade license for adding 25 VDOMs to FortiOS 5.4 and later, limited by platform maximum VDOM capacity. Virtual Domain License Add 50FG-VDOM-50-UG Upgrade license for adding 50 VDOMs to FortiOS 5.4 and later, limited by platform maximum VDOM capacity. Virtual Domain License Add 240FG-VDOM-240-UG Upgrade license for adding 240 VDOMs to FortiOS 5.4 and later, limited by platform maximum VDOM capacity. The number of configurable VDOMs can be stacked up to the maximum number of supported VDOMs per vCPU model. Please refer to Virtual Domains (Maximum) under SPECIFICATIONS.The following SKUs adopt the annual subscription licensing scheme:FortiGate S Series 6.4.8/7.0.2 or higher. This is a seat SKU where the total number of vdoms must beadded as seats in an increment of 5 and the minimal order is 5 vdomsFortiOS 6.2.3+ and 6.4.0+ support the FortiGate-VM S-series. The FortiGate-VM S-series does not have RAM restriction on all vCPU levels.FortiManager 6.2.3+ and 6.4.0+ support managing FortiGate-VM S-series devices. However, only specific FortiManager versions support NSX-T integration. Refer to System Requirements.SubscriptionsFortiGuard BundlesFortiGuard Labs delivers a number of security intelligence services to augment the FortiGate firewall platform. You can easily optimize the protection capabilities of your FortiGate with one of these FortiGuard Bundles.FortiCare EliteFortiCare Elite offers enhanced SLAs and quick issue resolution through a dedicated support team. It provides single-touch ticket handling, extended Extended End-of-Engineering-Support for 18 months, and access to the new FortiCare Elite Portal for a unified view of device and security health.Service Category Service Offering A-la-carteBundlesEnterprise ProtectionUnified Threat ProtectionAdvanced ThreatProtectionFortiGuard Security ServicesIPS Service••••Anti-Malware Protection (AMP) — Antivirus, Mobile Malware, Botnet, CDR, Virus Outbreak Protection and FortiSandbox Cloud Service ••••URL, DNS & Video Filtering Service •••Anti-Spam••AI-based Inline Malware Prevention Service ••Data Loss Prevention Service 1••OT Security Service (OT Detection, OT Vulnerability correlation, Virtual Patching, OT Signature / Protocol Decoders) 1•Application Control included with FortiCare Subscription CASB SaaS Controlincluded with FortiCare SubscriptionSD-WAN and SASE ServicesSD-WAN Underlay Bandwidth and Quality Monitoring Service •SD-WAN Overlay-as-a-Service for SaaS-based overlay network provisioning•SD-WAN Connector for FortiSASE Secure Private Access•FortiSASE subscription including cloud management and 10Mbps bandwidth license 2•NOC and SOC ServicesFortiGuard Attack Surface Security Service (IoT Detection, IoT Vulnerability Correlation, and Security Rating Updates) 1••FortiConverter Service ••Managed FortiGate Service•FortiGate Cloud (SMB Logging + Cloud Management) •FortiAnalyzer Cloud•FortiAnalyzer Cloud with SOCaaS •FortiGuard SOCaaS•Hardware and Software SupportFortiCare Essentials •FortiCare Premium ••••FortiCare Elite•Base ServicesInternet Service (SaaS) DB Updates included with FortiCare SubscriptionGeoIP DB UpdatesDevice/OS Detection Signatures Trusted Certificate DB Updates DDNS (v4/v6) Service1. Full features available when running FortiOS 7.4.12. Desktop Models onlyFortinet CSR PolicyFortinet is committed to driving progress and sustainability for all through cybersecurity,with respect for human rights and ethical business practices, making possible a digitalworld you can always trust. You represent and warrant to Fortinet that you will notuse Fortinet’s products and services to engage in, or support in any way, violationsor abuses of human rights, including those involving illegal censorship, surveillance,detention, or excessive use of force. Users of Fortinet products are required to complywith the Fortinet EULA and report any suspected violations of the EULA via theprocedures outlined in the Fortinet Whistleblower Policy. Copyright © 2023 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.。
abstracthardwareabstractionlayer类方法-回复AbstractHardwareAbstractionLayer类方法：在计算机科学中，AbstractHardwareAbstractionLayer（抽象硬件抽象层）是一个用于简化硬件与软件之间交互的重要概念。
该类方法的目标是隐藏硬件的细节，提供一组抽象化的接口，以便开发人员能够更轻松地开发软件，并使软件能够在不同硬件平台上运行。
在本文中，我们将一步一步地回答有关AbstractHardwareAbstractionLayer类方法的问题，以便更好地理解其工作原理和应用。
第一步：理解抽象硬件抽象层（Abstract Hardware Abstraction Layer）抽象硬件抽象层是一种软件技术，目的是提供一个统一的接口来访问不同硬件平台上的设备和资源。
它隐藏了底层硬件的细节，以便开发人员可以专注于软件开发，而不需要过多关注底层硬件的特性和差异。
抽象硬件抽象层通常由一组类和方法组成，用于封装底层硬件的功能和特性，并提供更高级别的接口供软件使用。
第二步：确定AbstractHardwareAbstractionLayer类的作用AbstractHardwareAbstractionLayer类是抽象硬件抽象层的一个具体实现。
它定义了一组核心方法和属性，用于实现硬件的抽象化和资源管理。
这些方法和属性通常包括设备初始化、数据传输、中断处理、资源分配和释放等功能。
AbstractHardwareAbstractionLayer类的目标是提供一个高效的、可扩展的接口，允许开发人员使用统一的方式访问不同硬件平台上的设备和资源。
第三步：深入研究AbstractHardwareAbstractionLayer类的方法AbstractHardwareAbstractionLayer类通常包含以下几个重要的方法：1. initialize(): 此方法用于初始化硬件设备，包括设置设备参数、分配内存和建立连接等。
第38卷第1期2021年1月控制理论与应用Control Theory&ApplicationsV ol.38No.1Jan.2021分数阶多机器人的领航–跟随型环形编队控制伍锡如†,邢梦媛(桂林电子科技大学电子工程与自动化学院,广西桂林541004)摘要:针对多机器人系统的环形编队控制复杂问题,提出一种基于分数阶多机器人的环形编队控制方法,应用领航–跟随编队方法来控制多机器人系统的环形编队和目标包围,通过设计状态估测器,实现对多机器人的状态估计.由领航者获取系统中目标状态的信息,跟随者监测到领航者的状态信息并完成包围环绕编队控制,使多机器人系统形成对动态目标的目标跟踪.根据李雅普诺夫稳定性理论和米塔格定理,得到多机器人系统环形编队控制的充分条件,实现对多机器人系统对目标物的包围控制,通过对一组多机器人队列的目标包围仿真,验证了该方法的有效性.关键词:分数阶;多机器人;编队控制;环形编队;目标跟踪引用格式:伍锡如,邢梦媛.分数阶多机器人的领航–跟随型环形编队控制.控制理论与应用,2021,38(1):103–109DOI:10.7641/CTA.2020.90969Annular formation control of the leader-follower multi-robotbased on fractional orderWU Xi-ru†,XING Meng-yuan(School of Electronic Engineering and Automation,Guilin University of Electronic Technology,Guilin Guangxi541004,China) Abstract:Aiming at the complex problem of annular formation control for fractional order multi robot system,an an-nular formation control method based on fractional order multi robot is proposed.The leader follower formation method is used to control the annular formation and target envelopment of the multi robot systems.The state estimation of multi robot is realized by designing state estimator.The leader obtains the information of the target state in the system,the followers detects the status of the leader and complete annular formation control,the multi-robot system forms the target tracking of the dynamic target.According to Lyapunov stability theory and Mittag Leffler’s theorem,the sufficient conditions of the annular formation control for the multi robot systems are obtained in order to achieve annular formation control of the leader follower multi robot.The effectiveness of the proposed method is verified by simulation by simulation of a group of multi robot experiments.Key words:fractional order;multi-robots;formation control;annular formation;target trackingCitation:WU Xiru,XING Mengyuan.Annular formation control of the leader-follower multi-robot based on fractional order.Control Theory&Applications,2021,38(1):103–1091引言近年来,随着机器人技术的崛起和发展,各式各样的机器人技术成为了各个领域不可或缺的一部分,推动着社会的发展和进步.与此同时,机器人面临的任务也更加复杂,单个机器人已经无法独立完成应尽的责任,这就使得多机器人之间相互协作、共同完成同一个给定任务成为当前社会的研究热点.多机器人系统控制的研究主要集中在一致性问题[1]、多机器人编队控制问题[2–3]、蜂拥问题[4–5]等.其中,编队控制问题作为多机器人系统的主要研究方向之一,是国内外研究学者关注的热点问题.编队控制在生活生产、餐饮服务尤其是军事作战等领域都发挥着极大的作用.例如水下航行器在水中的自主航行和编队控制、军事作战机对空中飞行器的打击以及无人机在各行业的应用等都是多机器人编队控制上的用途[6–7].目前,多机器人编队控制方法主要有3种,其中在多机器收稿日期:2019−11−25;录用日期:2020−08−10.†通信作者.E-mail:****************;Tel.:+86132****1790.本文责任编委:黄攀峰.国家自然科学基金项目(61603107,61863007),桂林电子科技大学研究生教育创新计划项目(C99YJM00BX13)资助.Supported by the National Natural Science Foundation of China(61603107,61863007)and the Innovation Project of GUET Graduate Education (C99YJM00BX13).104控制理论与应用第38卷人系统编队控制问题上应用最广泛的是领航–跟随法[8–10];除此之外,还有基于行为法和虚拟结构法[11].基于行为的多机器人编队方法在描述系统整体时不够准确高效,且不能保证系统控制的稳定性;而虚拟结构法则存在系统灵活性不足的缺陷.领航–跟随型编队控制法具有数学分析简单、易保持队形、通信压力小等优点,被广泛应用于多机器人系统编队[12].例如,2017年,Hu等人采用分布式事件触发策略,提出一种新的自触发算法,实现了线性多机器人系统的一致性[13];Zuo等人利用李雅普诺夫函数,构造具有可变结构的全局非线性一致控制律,研究多机器人系统的鲁棒有限时间一致问题[14].考虑到分数微积分的存储特性,开发分数阶一致性控制的潜在应用具有重要意义.时中等人于2016年设计了空间遥操作分数阶PID 控制系统,提高了机器人系统的跟踪性能、抗干扰性、鲁棒性和抗时延抖动性能[15].2019年,Z Yang等人探讨了分数阶多机器人系统的领航跟随一致性问题[16].而在多机器人的环形编队控制中,对具有分数阶动力学特性的多机器人系统的研究极其有限,大部分集中在整数阶的阶段.而采用分数阶对多机器人系统目标包围编队控制进行研究,综合考虑了非局部分布式的影响,更好地描述具有遗传性质的动力学模型.使得系统的模型能更准确的反映系统的性态,对多机器人编队控制的研究非常有利.目标包围控制问题是编队控制的一个分支,是多智能体编队问题的重点研究领域.随着信息技术的高速发展,很多专家学者对多机器人系统的目标包围控制问题进行了研究探讨.例如,Kim和Sugie于2017年基于一种循环追踪策略设计分布式反馈控制律,保证了多机器人系统围绕一个目标机器人运动[17].在此基础上,Lan和Yan进行了拓展,研究了智能体包围多个目标智能体的问题,并把这个问题分为两个步骤[18]. Kowdiki K H和Barai K等人则研究了单个移动机器人对任意时变曲线的跟踪包围问题[19].Asif M考虑了机器人与目标之间的避障问题,提出了两种包围追踪控制算法;并实现了移动机器人对目标机器人的包围追踪[20].鉴于以上原因,本文采用了领航–跟随型编队控制方法来控制多机器人系统的环形编队和目标包围,通过设计状态估测器,实现对多机器人的状态估计.系统中目标状态信息只能由领航者获取,确保整个多机器人系统编队按照预期的理想编队队形进行无碰撞运动,并最终到达目标位置,对目标、领航者和跟随者的位置分析如图1(a)所示,图1(b)为编队控制后的状态.通过应用李雅普诺夫稳定性理论,得到实现多机器人系统环形编队控制的充分条件.最后通过对一组多机器人队列进行目标包围仿真,验证了该方法的有效性.(a)编队控制前(b)编队控制后图1目标、领航者和追随者的位置分析Fig.1Location analysis of targets,pilots and followers2代数图论与分数阶基础假定一个含有N个智能体的系统,通讯网络拓扑图用G={v,ε}表示,定义ε=v×v为跟随者节点之间边的集合,v={v i,i=1,2,···,N}为跟随者节点的集合.若(v i,v j)∈ε,则v i与v j为相邻节点,定义N j(t)={i|(v i,v j)∈ε,v i∈v}为相邻节点j的标签的集合.那么称第j个节点是第i 个节点的邻居节点,用N j(t)={i|(v i,v j)∈ε,v i∈v}表示第i个节点的邻居节点集合.矩阵L=D−A称为与图G对应的拉普拉斯矩阵.其中:∆是对角矩阵,对角线元素i=∑jN i a ij.若a ij=a ji,i,j∈I,则称G是无向图,否则称为有向图.如果节点v i与v j之间一组有向边(v i,v k1)(v k1,v k2)(v k2,v k3)···(v kl,v j),则称从节点v i到v j存在有向路径.定义1Riemann-Liouville(RL)分数阶微分定义:RLD atf(t)=1Γ(n−a)d nd t ntt0f(τ)(t−τ)a−n+1dτ,(1)其中:t>t0,n−1<α<n,n∈Z+,Γ(·)为伽马函数.定义2Caputo(C)分数阶微分定义:CDαtf(t)=1Γ(n−α)tt0f n(τ)(t−τ)α−n+1dτ,(2)其中:t>t0,n−1<α<n,n∈Z+,Γ(·)为伽马第1期伍锡如等:分数阶多机器人的领航–跟随型环形编队控制105函数.定义3定义具有两个参数α,β的Mittag-Leffler方程为E α,β(z )=∞∑k =1z kΓ(αk +β),(3)其中:α>0,β>0.当β=1时,其单参数形式可表示为E α,1(z )=E α(z )=∞∑k =1z kΓ(αk +1).(4)引理1[21]假定存在连续可导函数x (t )∈R n ,则12C t 0D αt x T (t )x (t )=x T (t )C t 0D αt x (t ),(5)引理2[21]假定x =0是系统C t 0D αt x (t )=f (x )的平衡点,且D ⊂R n 是一个包含原点的域,R 是一个连续可微函数,x 满足以下条件:{a 1∥x ∥a V (t ) a 2∥x ∥ab ,C t 0D αt V (t ) −a 3∥x ∥ab,(6)其中:t 0,x ∈R ,α∈(0,1),a 1,a 2,a 3,a,b 为任意正常数,那么x =0就是Mittag-Leffler 稳定.3系统环形编队控制考虑包含1个领航者和N 个跟随者的分数阶非线性多机器人系统.领航者的动力学方程为C t 0D αt x 0(t )=u 0(t ),(7)式中:0<α<1,x 0(t )∈R 2是领航者的位置状态,u 0(t )∈R 2是领航者的控制输入.跟随者的动力学模型如下:C t 0D αt x i (t )=u i (t ),i ∈I,(8)式中:0<α<1,x i (t )∈R 2是跟随者的位置状态,u i (t )∈R 2是跟随者i 在t 时刻的控制输入,I ={1,2,···,N }.3.1领航者控制器的设计对于领航者,选择如下控制器:u 0(t )=−k 1(x 0(t )−˜x 0(t ))−k 2sgn(x 0(t )−˜x 0(t )),(9)C t 0D αt x 0(t )=u 0(t )=−k 1(x 0(t )−˜x 0(t ))−k 2sgn(x 0(t )−˜x 0(t )).(10)设计一个李雅普诺夫函数:V (t )=12(x 0(t )−˜x 0(t ))T (x 0(t )−˜x 0(t )).(11)根据引理1,得到该李雅普诺夫函数的α阶导数如下:C 0D αt V(t )=12C 0D αt (x 0(t )−˜x 0(t ))T (x 0(t )−˜x 0(t )) (x 0(t )−˜x 0(t ))TC 0D αt (x 0(t )−˜x0(t ))=(x 0(t )−˜x 0(t ))T [C 0D αt x 0(t )−C 0D αt ˜x0(t )]=(x 0(t )−˜x 0(t ))T [−k 1(x 0(t )−˜x 0(t ))−k 2sgn(x 0(t )−˜x 0(t ))−C 0D αt ˜x0(t )]=−k 1(x 0(t )−˜x 0(t ))T (x 0(t )−˜x 0(t ))−k 2∥x 0(t )−˜x 0(t )∥−(x 0(t )−˜x 0(t ))TC 0D αt ˜x0(t )=−2k 1V (t )−k 2∥x 0(t )−˜x 0(t )∥+∥C 0D αt ˜x0(t )∥∥x 0(t )−˜x 0(t )∥=−2k 1V (t )−(k 2−∥C 0D ∝t ˜x0(t )∥)∥x 0(t )−˜x 0(t )∥ −2k 1V (t ).(12)令a 1=a 2=12,a 3=2k 1,ab =2,a >0,b >0,得到a 1∥x 0(t )−˜x 0(t )∥a V (t ) a 2∥x 0(t )−˜x 0(t )∥ab ,(13)C t 0D αt V(t ) −a 3∥x 0(t )−˜x 0(t )∥ab .(14)根据引理2,可知lim t →∞∥x 0(t )−˜x 0(t )∥=0,即x 0(t )逐渐趋近于˜x 0(t ).为了使跟随者能够跟踪观测到领航者的状态,设计了一个状态估测器.令ˆx i ∈R 2是追随者对领航者的状态估计,给出了ˆx i 的动力学方程C 0D αt ˆx i=β(∑j ∈N ia ij g ij (t )+d i g i 0(t )),(15)其中g ij =˜x j (t )−˜x i (t )∥˜x j (t )−˜x i (t )∥,˜x j (t )−˜x i (t )=0,0,˜x j (t )−˜x i (t )=0.(16)对跟随者取以下李雅普诺夫函数:V (t )=12N ∑i =1(ˆx i (t )−x 0(t ))T (ˆx i (t )−x 0(t )).(17)计算该函数的α阶导数如下:C 0D αt V(t )=12C 0D αtN ∑i =1(ˆx i (t )−x 0(t ))T (ˆx i (t )−x 0(t )) N ∑i =1(ˆx i (t )−x 0(t ))TC 0D αt (ˆx i (t )−x 0(t ))=N ∑i =1(ˆx i (t )−x 0(t ))T [C 0D αt ˆxi (t )−C 0D αt x 0(t )]=N ∑i =1(ˆx i (t )−x 0(t ))T [β(∑j ∈N ia ijˆx j (t )−ˆx i (t )∥ˆx j (t )−ˆx i (t )∥+d iˆx 0(t )−ˆx i (t )∥ˆx 0(t )−ˆx i (t )∥)−C 0D αt x 0(t )]=N ∑i =1(ˆx i (t )−x 0(t ))T β(∑j ∈N i a ij ˆx j (t )−ˆx i (t )∥ˆx j (t )−ˆx i(t )∥+106控制理论与应用第38卷d iˆx 0(t )−ˆx i (t )∥ˆx 0(t )−ˆx i (t )∥)−N ∑i =1(ˆx i (t )−x 0(t ))TC 0D αt x 0(t )=βN ∑i =1(ˆx i (t )−x 0(t ))T ∑j ∈N i a ij ˆx j (t )−ˆx i (t )∥ˆx j (t )−ˆx i (t )∥+βN ∑i =1(ˆx i (t )−x 0(t ))Td i ˆx 0(t )−ˆx i (t )∥ˆx 0(t )−ˆx i(t )∥−N ∑i =1(ˆx i (t )−x 0(t ))TC 0D αt x 0(t ).(18)在上式中,令C 0D αt V (t )=N 1+N 2以方便后续计算,其中:N 1=βN ∑i =1(ˆx i (t )−x 0(t ))T ∑j ∈N i a ij ˆx j (t )−ˆx i (t )∥ˆx j (t )−ˆx i (t )∥+βN ∑i =1(ˆx i (t )−x 0(t ))Td i ˆx 0(t )−ˆx i (t )∥ˆx 0(t )−ˆx i (t )∥=β2[N ∑i =1N ∑j =1a ij (ˆx i (t )−x 0(t ))T ˆx j (t )−ˆx i (t )∥ˆx j (t )−ˆx i (t )∥+N ∑j =1N ∑i =1a ij (ˆx j (t )−x 0(t ))Tˆx i (t )−ˆx j (t )∥ˆx i (t )−ˆx j (t )∥]−βN ∑i =1d i∥ˆx 0(t )−ˆx i (t )∥2∥ˆx 0(t )−ˆx i (t )∥=β2N ∑i =1N ∑j =1a ij [(ˆx i (t )−x 0(t ))Tˆx j (t )−ˆx i (t )∥ˆx j (t )−ˆx i (t )∥−(ˆx j (t )−x 0(t ))T ˆx i (t )−ˆx j (t )∥ˆx i (t )−ˆx j (t )∥]−βN ∑i =1d i∥ˆx 0(t )−ˆx i (t )∥2∥ˆx 0(t )−ˆx i (t )∥=β2N ∑i =1N ∑j =1a ij [ˆx T i(t )ˆx j (t )−ˆx i (t )∥ˆx j (t )−ˆx i (t )∥−x T 0(t )ˆx j (t )−ˆx i (t )∥ˆx j (t )−ˆx i (t )∥−ˆx T j(t )ˆx i (t )−ˆx j (t )∥ˆx i (t )−ˆx j (t )∥+x T0(t )ˆx i (t )−ˆx j (t )∥ˆx i (t )−ˆx j (t )∥]−βN ∑i =1d i ∥ˆx 0(t )−ˆx i (t )∥=β2N ∑i =1N ∑j =1a ij [ˆx T i (t )ˆx j (t )−ˆx i (t )∥ˆx j (t )−ˆx i (t )∥−ˆx T j (t )ˆx i (t )−ˆx j (t )∥ˆx i (t )−ˆx j (t )∥]−βN ∑i =1d i ∥ˆx 0(t )−ˆx i (t )∥2∥ˆx 0(t )−ˆx i (t )∥=β2N ∑i =1N ∑j =1a ij (ˆx T i(t )−ˆx Tj (t ))ˆx j (t )−ˆx i (t )∥ˆx j (t )−ˆx i (t )∥−βN ∑i =1d i ∥ˆx 0(t )−ˆx i (t )∥2∥ˆx 0(t )−ˆx i (t )∥=−β(12N ∑i =1N ∑j =1a ij (ˆx T j (t )−ˆx T i (t ))׈x j (t )−ˆx i (t )∥ˆx j (t )−ˆx i (t )∥+N ∑i =1d i ∥ˆx 0(t )−ˆx i (t )∥2∥ˆx 0(t )−ˆx i (t )∥),(19)N 2=−N ∑i =1(ˆx i (t )−x 0(t ))TC 0D αt x 0(t )=N ∑i =1∥ˆx i (t )−x 0(t )∥∥C 0D αt x 0(t )∥×cos {ˆx i (t )−x 0(t ),−C 0D αt x 0(t )}.(20)由于∥C 0D αt x 0(t )∥k 1∥x 0(t )−˜x 0(t )∥+k 2∥sgn(x 0(t )−˜x 0(t ))∥ k 1∥x 0(t )−˜x 0(t )∥+k 2.(21)根据定义3,当lim t →∞∥x 0(t )−˜x 0(t )∥=0时,存在T >0(T 为实数),使得在t >T 时∥x 0(t )−˜x 0(t )∥ ε成立,那么对于t >T ,有0<∥C 0D αt x 0(t )∥ k 1ε+k 2=M 2,可得−N ∑i =1(ˆx i (t )−x 0(t ))TC 0D αt x 0(t )N ∑i =1∥ˆx i (t )−x 0(t )∥M 2M 2N max {∥ˆx i (t )−x 0(t )∥},(22)C 0D αt V(t ) −(β−M 2N )max i ∈I{∥ˆx i (t )−x 0(t )∥}−2β1λmin V (t ).(23)根据引理2,得lim t →∞∥ˆx i (t )−x 0(t )∥=0.(24)由上式可知,ˆx i (t )在对目标的追踪过程中逐渐趋近于x 0(t ).3.2跟随者控制器的设计在本文中,整个多机器人系统中领导者能够直接获得目标的位置信息,将这些信息传递给追随者,因此需要为每个追随者设计观测器来估计目标的状态.令ϕi (t )∈R 2由跟随者对目标i 的状态估计,给出ϕi (t )的动力学方程C 0D αt ϕi(t )=α(∑j ∈N ia ij f ij (t )+d i f i 0(t )),(25)其中f ij =ϕj (t )−ϕi (t )∥ϕj (t )−ϕi (t )∥,ϕj (t )−ϕi (t )=0,0,ϕj (t )−ϕi (t )=0.(26)取如下李雅普诺夫函数:V (t )=12N ∑i =1(ϕi (t )−r (t ))T (ϕi (t )−r (t )).(27)计算α阶导数如下:C 0D αt V(t )=第1期伍锡如等:分数阶多机器人的领航–跟随型环形编队控制10712N ∑i =1(ϕi (t )−r (t ))T (ϕi (t )−r (t )) N ∑i =1(ϕi (t )−r (t ))TC 0D αt (ϕi (t )−r (t ))=N ∑i =1(ϕi (t )−r (t ))T [C 0D αt ϕi (t )−C 0D αt r (t )]=N ∑i =1(φi (t )−r (t ))T [α(∑j ∈N ia ij f ij (t )+d i f i 0(t ))]−C 0D αt r (t )=N ∑i =1(ϕi (t )−r (t ))T α(∑j ∈N ia ij ϕj (t )−ϕi (t )∥ϕj (t )−ϕi (t )∥+d i ϕ(t )−ϕi (t )∥ϕ(t )−ϕi (t )∥)=βN ∑i =1(ϕi (t )−r (t ))T ∑j ∈N i a ijϕj (t )−ϕi (t )∥ϕj (t )−ϕi(t )∥+βN ∑i =1(ϕi (t )−r (t ))T d i ϕ(t )−ϕi (t )∥ϕ(t )−ϕi(t )∥−N ∑i =1(ϕi (t )−r (t ))TC 0D αt r (t ),(28)可得lim t →∞∥x i (t )−˜x i (t )∥=0.(29)由上式可知,x i (t )在对目标的追踪过程中逐渐趋近于˜x i (t ).4仿真结果与分析本节通过仿真结果来验证本文所提出的方法.图2为通信图,其中:V ={1,2,3,4}表示跟随者集合,0代表领导者.以5个机器人组成的队列为例进行验证,根据领航者对目标的跟随轨迹,分别进行了仿真.图2通信图Fig.2Communication diagrams假设系统中目标机器人的动态为C 0D αt r (t )=[cos t sin t ]T ,令初始值r 1(0)=r 2(0)=1,α=0.98,k 1=1,k 2=4,可知定理3中的条件是满足的.根据式(24)和式(29),随着时间趋于无穷,领航者及其跟随者的状态估计误差趋于0,这意味着领航者的状态可以由跟随者渐近精确地计算出来.令k 2>M 1,M 1=M +M ′>0,则lim t →∞∥x 0(t )−˜x 0(t )∥=0,x 0渐近收敛于领航者的真实状态.此时取时滞参数µ=0.05,实验结果见图3,由1个领航者及4个跟随者组成的多机器人系统在进行目标围堵时,最终形成了以目标机器人为中心的包围控制(见图3(b)).(a)领航者和跟随者的初始位置分析(b)编队形成后多机器人的位置关系图3目标、领航者和追随者的位置分析Fig.3Location analysis of target pilots and followers综合图4–5曲线,跟随者对领航者进行渐进跟踪,领航者同目标机器人的相对位置不变,表明该领航跟随型多机器人系统最终能与目标机器人保持期望的距离,并且不再变化.图4领航者及其跟随者的状态估计误差Fig.4The state estimation error of the leader and followers108控制理论与应用第38卷图5编队形成时领航者与目标的相对位置关系Fig.5The relative position relationship between leader andtarget仿真结果表明,多个机器人在对目标物进行包围编队时,领航者会逐渐形成以目标物运动轨迹为参照的运动路线,而跟随者则渐近的完成对领航者的跟踪(如图6所示),跟随者在对领航者进行跟踪时,会出现一定频率的抖振,但这些并不会影响该多机器人系统的目标包围编队控制.5总结本文提出了多机器人的领航–跟随型编队控制方法,选定了一台机器人作为领航者负责整个编队的路径规划任务,其余机器人作为跟随者.跟随机器人负责实时跟踪领航者,并尽可能与领航机器人之间保持队形所需的距离和角度,确保整个多机器人系统编队按照预期的理想编队队形进行无碰撞运动,并最终到达目标位置.通过建立李雅普诺夫函数和米塔格稳定性理论,得到了实现多机器人系统环形编队的充分条件,并通过对一组多机器人队列的目标包围仿真,验证了该方法的有效性.图6领航者与跟随者对目标的状态估计Fig.6State estimation of target by pilot and follower参考文献:[1]JIANG Yutao,LIU Zhongxin,CHEN Zengqiang.Distributed finite-time consensus algorithm for multiple nonholonomic mobile robots with disturbances.Control Theory &Applications ,2019,36(5):737–745.(姜玉涛,刘忠信,陈增强.带扰动的多非完整移动机器人分布式有限时间一致性控制.控制理论与应用,2019,36(5):737–745.)[2]ZHOU Chuan,HONG Xiaomin,HE Junda.Formation control ofmulti-agent systems with time-varying topology based on event-triggered mechanism.Control and Decision ,2017,32(6):1103–1108.(周川,洪小敏,何俊达.基于事件触发的时变拓扑多智能体系统编队控制.控制与决策,2017,32(6):1103–1108.)[3]ZHANG Ruilei,LI Sheng,CHEN Qingwei,et al.Formation controlfor multi-robot system in complex terrain.Control Theory &Appli-cations ,2014,31(4):531–537.(张瑞雷,李胜,陈庆伟,等.复杂地形环境下多机器人编队控制方法.控制理论与应用,2014,31(4):531–537.)[4]WU Jin,ZHANG Guoliang,ZENG Jing.Discrete-time modeling formultirobot formation and stability of formation control algorithm.Control Theory &Applications ,2014,31(3):293–301.(吴晋,张国良,曾静.多机器人编队离散模型及队形控制稳定性分析.控制理论与应用,2014,31(3):293–301.)[5]WANG Shuailei,ZHANG Jinchun,CAO Biao.Target tracking al-gorithm with double-type agents based on flocking control.Control Engineering of China ,2019,26(5):935–940.(王帅磊,张金春,曹彪.双类型多智能体蜂拥控制目标跟踪算法.控制工程,2019,26(5):935–940.)[6]SHAO Zhuang,ZHU Xiaoping,ZHOU Zhou,et al.Distributed for-mation keeping control of UA Vs in 3–D dynamic environment.Con-trol and Decision ,2016,31(6):1065–1072.(邵壮,祝小平,周洲,等.三维动态环境下多无人机编队分布式保持控制.控制与决策,2016,31(6):1065–1072.)[7]PANG Shikun,WANG Jian,YI Hong.Formation control of multipleautonomous underwater vehicles based on sensor measuring system.Journal of Shanghai Jiao Tong University ,2019,53(5):549–555.(庞师坤,王健,易宏.基于传感探测系统的多自治水下机器人编队协调控制.上海交通大学学报,2019,53(5):549–555.)[8]WANG H,GUO D,LIANG X.Adaptive vision-based leader-followerformation control of mobile robots.IEEE Transactions on Industrial Electronics ,2017,64(4):2893–2902.[9]LI R,ZHANG L,HAN L.Multiple vehicle formation control basedon robust adaptive control algorithm.IEEE Intelligent Transportation Systems Magazine ,2017,9(2):41–51.[10]XING C,ZHAOXIA P,GUO G W.Distributed fixed-time formationtracking of multi-robot systems with nonholonomic constraints.Neu-rocomputing ,2018,313(3):167–174.[11]LOPEZ-GONZALEA A,FERREIRA E D,HERNANDEZ-MAR-TINEZ E G.Multi-robot formation control using distance and ori-entation.Advanced Robotics ,2016,30(14):901–913.[12]DIMAROGONAS D,FRAZZOLI E,JOHNSSON K H.Distributedevent-triggered control for multi-agent systems.IEEE Transactions on Automatic Control ,2019,57(5):1291–1297.[13]HU W,LIU L,FENG G.Consensus of linear multi-agent systems bydistributed event-triggered strategy.IEEE Transactions on Cybernet-ics ,2017,46(1):148–157.第1期伍锡如等:分数阶多机器人的领航–跟随型环形编队控制109[14]ZUO Z,LIN T.Distributed robustfinite-time nonlinear consensusprotocols for multi-agent systems.International Journal of Systems Science,2016,47(6):1366–1375.[15]SHI Zhong,HUANG Xuexiang,TAN Qian.Fractional-order PIDcontrol for teleoperation of a free-flying space robot.Control The-ory&Applications,2016,33(6):800–808.(时中,黄学祥,谭谦.自由飞行空间机器人的遥操作分数阶PID控制.控制理论与应用,2016,33(6):800–808.)[16]YANG Z C,ZHENG S Q,LIU F.Adaptive output feedback con-trol for fractional-order multi-agent systems.ISA Transactions,2020, 96(1):195–209.[17]LIU Z X,CHEN Z Q,YUAN Z Z.Event-triggered average-consensusof multi-agent systems with weighted and directed topology.Journal of Systems Science and Complexity,2016,25(5):845–855.[18]AI X L,YU J Q.Flatness-basedfinite-time leader-follower formationcontrol of multiple quad rotors with external disturbances.Aerospace Science and Technology,2019,92(9):20–33.[19]KOWDIKI K H,BARAI K,BHATTACHARYA S.Leader-followerformation control using artificial potential functions:A kinematic ap-proach.IEEE International Conference on Advances in Engineering.Tamil Nadu,India:IEEE,2012:500–505.[20]ASIF M.Integral terminal sliding mode formation control of non-holonomic robots using leader follower approach.Robotica,2017, 1(7):1–15．[21]CHEN W,DAI H,SONG Y,et al.Convex Lyapunov functions forstability analysis of fractional order systems.IET Control Theory& Applications,2017,11(7):1070–1074．作者简介:伍锡如博士,教授,硕士生导师,目前研究方向为机器人控制、神经网络、深度学习等,E-mail:***************.cn;邢梦媛硕士研究生,目前研究方向为多机器人编队控制,E-mail: ****************.。
现代电子技术Modern Electronics Technique2021年12月15日第44卷第24期Dec.2021Vol.44No.240引言测试性是装备通用质量的特性之一，对装备完好性具有重要影响，测试性验证是测试性工作的重要环节，其方法研究受到了广泛关注[1]。
目前，基于实物的测试性验证存在装备故障注入后损坏或故障不能注入的风险，因此国内部分高校和研究所开展了基于虚拟仿真机的测试性虚拟验证的研究。
杨金鹏等人总结测试性实物验证与非实物验证发展现状，分析了两种验证方法未来的发展趋势，肯定了测试性虚拟验证的必要性与可行性[2]。
刘城总结并优化了测试性虚拟验证方案，利用PSPCIE 平台进行带通滤波器虚拟建模，通过故障注入验证了其测试性虚拟验证平台的准确性[3]。
童陈敏提出了基于Modelica 的测试性虚拟验证系统，将模拟的故障注入FSFTC 模型中以此完成装备的测试性验证[4]。
测试性虚拟验证的本质是将基于实物的测试性验证过程虚拟化，避免故障注入造成其不可逆的损坏。
通DOI ：10.16652/j.issn.1004⁃373x.2021.24.010引用格式：杨建军，陈立，李善强，等.基于智能体的装备测试性虚拟验证系统[J].现代电子技术，2021，44（24）：43⁃48.基于智能体的装备测试性虚拟验证系统杨建军1，2，陈立1，2，李善强1，聂磊1（1.湖北工业大学机械工程学院，湖北武汉430068；2.航天科工武汉磁电有限责任公司，湖北武汉430074）摘要：针对目前测试性虚拟验证过程中存在故障传播可视化程度低及故障注入真实感不足等问题，文中提出利用多智能体建模技术建立装备可视化仿真机模型的方法。
首先建立装备可视化仿真机中各部件智能体及其状态转移图，然后建立各部件智能体通信机制实现数据交互，接着利用LabVIEW 搭建测试机实现验证方案选取、故障样本分配等功能，最后运用TCP 通信技术联通测试机与仿真机，进行虚拟故障编号注入，由此完成装备测试性虚拟验证过程。
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.。
