VMM验证方法学研究及SystemC实现(硕士论文)

基于VMM验证方法的研究的开题报告一、选题背景与意义虚拟化技术是一种能够在一个物理主机上同时运行多个虚拟机的技术，它通过将物理计算机资源抽象成为一系列的虚拟资源，从而实现对计算机资源的更加高效地利用，具有快速部署、资源隔离和动态扩展等优势，在云计算、大数据和物联网等领域得到了广泛应用。

虚拟机管理器（VMM）是虚拟化技术的核心，它可以协调和管理物理计算机上所有的虚拟机的存储、网络和计算资源。

随着虚拟化技术的成熟和应用范围的不断扩大，VMM的安全性问题越来越受到重视。

例如，虚拟机可以通过VMM来攻击物理主机，窃取敏感数据，甚至攻击其他虚拟机。

因此，对VMM进行安全验证是十分必要的。

目前，已经有许多针对VMM的安全验证方法得到了广泛应用，例如符号执行、模型检测和随机测试等方法。

这些方法都具有一定的优势和局限性，但是它们都没有解决所有的VMM安全问题，因此我们需要探索更加有效的VMM安全验证方法。

二、研究内容和目标本课题希望通过对现有的VMM安全验证方法的研究和综合分析，提出一种基于VMM的验证方法，以彻底解决现有方法的不足之处。

具体来说，研究内容和目标如下：1、分析和比较现有的VMM安全验证方法，并挖掘它们的优劣之处。

2、提出一种基于VMM的安全验证方法，该方法能够解决现有方法存在的问题，并具有更高的效率和可扩展性。

3、实现所提出的安全验证方法，并使用流行的虚拟化平台进行验证和评估。

三、研究方法和技术路线本课题采用文献调研、实验验证和数据分析等方法，具体技术路线如下：1、文献调研，重点梳理比较现有的VMM安全验证方法，并总结它们的优劣。

2、提出一种基于VMM的验证方法，设计并实现算法和程序。

3、使用流行的虚拟化平台进行验证和评估，收集数据并进行分析。

四、研究预期成果通过本次研究，我们预计可以取得以下成果：1、总结比较现有的VMM安全验证方法，并挖掘它们的优劣之处。

2、提出一种基于VMM的安全验证方法，能够彻底解决现有方法的不足之处，并具有更高的效率和可扩展性。

计算机研究与发展ＩＳＳＮ　１０００－１２３９?ＣＮ　１１－１７７７?ＴＰＪｏｕｒｎａｌ　ｏｆ　Ｃｏｍｐｕｔｅｒ　Ｒｅｓｅａｒｃｈ　ａｎｄ　Ｄｅｖｅｌｏｐｍｅｎｔ　４８（８）：１４３８－１４４６，２０１１基于ＶＭＭ层系统调用分析的软件完整性验证李　博　李建欣　胡春明　沃天宇　怀进鹏（北京航空航天大学计算机学院　北京　１００１９１）（ｌｉｂｏ＠ａｃｔ．ｂｕａａ．ｅｄｕ．ｃｎ）Ｓｏｆｔｗａｒｅ　Ｉｎｔｅｇｒｉｔｙ　Ｖｅｒｉｆｉｃａｔｉｏｎ　Ｂａｓｅｄ　ｏｎ　ＶＭＭ－Ｌｅｖｅｌ　Ｓｙｓｔｅｍ　Ｃａｌｌ　ＡｎａｌｙｓｉｓＴｅｃｈｎｉｑｕｅＬｉ　Ｂｏ，Ｌｉ　Ｊｉａｎｘｉｎ，Ｈｕ　Ｃｈｕｎｍｉｎｇ，Ｗｏ　Ｔｉａｎｙｕ，ａｎｄ　Ｈｕａｉ　Ｊｉｎｐｅｎｇ（Ｓｃｈｏｏｌ　ｏｆ　Ｃｏｍｐｕｔｅｒ　Ｓｃｉｅｎｃｅ　ａｎｄ　Ｅｎｇｉｎｅｅｒｉｎｇ，Ｂｅｉｈａｎｇ　Ｕｎｉｖｅｒｓｉｔｙ，Ｂｅｉｊｉｎｇ１００１９１）Ａｂｓｔｒａｃｔ　Ｉｎ　ｖｉｒｔｕａｌｉｚｅｄ　ｃｌｏｕｄ　ｃｏｍｐｕｔｉｎｇ　ｐｌａｔｆｏｒｍ，ｔｈｅ　ｋｅｙ　ｓｅｃｕｒｉｔｙ　ｐｒｏｂｌｅｍ　ｉｓ　ｔｏ　ｇｕａｒａｎｔｅｅｔｒｕｓｔｗｏｒｔｈｉｎｅｓｓ　ｏｆ　ｔｈｅ　ｓｏｆｔｗａｒｅｓ　ｗｈｉｃｈ　ａｒｅ　ｒｕｎｎｉｎｇ　ｉｎ　ｔｈｅ　ｐｌａｔｆｏｒｍ．Ｉｎｔｅｇｒｉｔｙ　ｍｅａｓｕｒｅｍｅｎｔ　ａｎｄｖｅｒｉｆｉｃａｔｉｏｎ　ｈａｓ　ｂｅｅｎ　ｐｒｏｐｏｓｅｄ　ａｎｄ　ｓｔｕｄｉｅｄ　ｂｙ　ｍａｎｙ　ｒｅｓｅａｒｃｈｅｒｓ　ａｓ　ａｎ　ｅｆｆｅｃｔｉｖｅ　ｗａｙ　ｔｏ　ｖｅｒｉｆｙ　ｔｈｅｉｎｔｅｇｒｉｔｙ　ｏｆ　ｃｏｍｐｕｔｅｒ　ｓｙｓｔｅｍｓ．Ｈｏｗｅｖｅｒ，ｅｘｉｓｔｉｎｇ　ａｐｐｒｏａｃｈｅｓ　ｈａｖｅ　ｓｏｍｅ　ｌｉｍｉｔａｔｉｏｎｓ　ｏｎ　ｃｏｍｐａｔｉｂｉｌｉｔｙ，ｓｅｃｕｒｉｔｙ　ａｎｄ　ｍａｉｎｔａｉｎａｂｉｌｉｔｙ，ａｎｄ　ｃａｎｎｏｔ　ｂｅ　ａｐｐｌｉｅｄ　ｉｎｔｏ　ｔｈｅ　ｃｌｏｕｄ　ｃｏｍｐｕｔｉｎｇ　ｐｌａｔｆｏｒｍ．Ｉｎ　ｔｈｉｓ　ｐａｐｅｒ，ｗｅ　ｐｒｏｐｏｓｅ　ａ　ａｐｐｒｏａｃｈ　ｎａｍｅｄ　ＶＭＧｕａｒｄ，ｗｈｉｃｈ　ｌｅｖｅｒａｇｅｓ　ＶＭＭ　ｔｏ　ｅｎａｂｌｅ　ｔａｋｅ　ｉｎｔｅｇｒｉｔｙ　ｍｅａｓｕｒｅｍｅｎｔｏｕｔｓｉｄｅ　ｔｈｅ　ｏｐｅｒａｔｉｎｇ　ｓｙｓｔｅｍ．Ｗｅ　ａｄｏｐｔ　ＶＭＭ－ｂａｓｅｄ　ｓｙｓｔｅｍ　ｃａｌｌ　ｉｎｔｅｒｃｅｐｔｉｏｎ　ｔｅｃｈｎｉｑｕｅ　ｔｏ　ｄｅｔｅｃｔ　ｔｈｅｅｘｅｃｕｔｉｏｎ　ｏｆ　ｂｉｎａｒｉｅｓ．Ｓｙｓｔｅｍ　ｃａｌｌ　ｃｏｒｒｅｌａｔｉｏｎ　ａｎｄ　ｇｕｅｓｔ　ＯＳ　ｆｉｌｅ　ｓｙｓｔｅｍ　ｍｅｔａｄａｔａ　ｒｅｃｏｎｓｔｒｕｃｔｉｏｎ　ａｒｅｐｒｏｐｏｓｅｄ　ｔｏ　ｖｅｒｉｆｙ　ｔｈｅ　ｉｎｔｅｇｒｉｔｙ　ｏｆ　ｓｏｆｔｗａｒｅ　ｉｎ　ｇｕｅｓｔ　ＯＳ．Ｗｅ　ｈａｖｅ　ｄｅｖｅｌｏｐｅｄ　ａ　ｐｒｏｔｏｔｙｐｅ　ｏｆ　ＶＭＧｕａｒｄａｎｄ　ｉｍｐｌｅｍｅｎｔｅｄ　ｉｔ　ｉｎ　ｔｗｏ　ｍａｉｎｓｔｒｅａｍ　ｖｉｒｔｕａｌ　ｍａｃｈｉｎｅ　ｍｏｎｉｔｏｒｓ，Ｑｅｍｕ　ａｎｄ　ＫＶＭ，ｒｅｓｐｅｃｔｉｖｅｌｙ．Ｗｅａｌｓｏ　ｅｖａｌｕａｔｅ　ｔｈｅ　ｅｆｆｅｃｔｉｖｅｎｅｓｓ　ａｎｄ　ｐｅｒｆｏｒｍａｎｃｅ　ｏｖｅｒｈｅａｄ　ｏｆ　ｏｕｒ　ａｐｐｒｏａｃｈ　ｂｙ　ｃｏｍｐｒｅｈｅｎｓｉｖｅｅｘｐｅｒｉｍｅｎｔｓ．Ｔｈｅ　ｒｅｓｕｌｔｓ　ｓｈｏｗ　ｔｈａｔ　ＶＭＧｕａｒｄ　ａｃｈｉｅｖｅｓ　ｅｆｆｅｃｔｉｖｅ　ｉｎｔｅｇｒｉｔｙ　ｍｅａｓｕｒｅｍｅｎｔ　ｗｉｔｈ　ｌｅｓｓ　ｔｈａｎ１０％ｏｖｅｒｈｅａｄ．Ｋｅｙ　ｗｏｒｄｓ　ｃｌｏｕｄ　ｃｏｍｐｕｔｉｎｇ；ｖｉｒｔｕａｌｉｚａｔｉｏｎ；ｉｎｔｅｇｒｉｔｙ　ｖｅｒｉｆｉｃａｔｉｏｎ；ｓｙｓｔｅｍ　ｃａｌｌ　ａｎａｌｙｓｉｓ；ｓｏｆｔｗａｒｅｌｏａｄｉｎｇ摘　要　在虚拟化云计算平台中，如何保证其上运行软件的可信性是云平台广泛应用的关键．完整性测量与验证技术是保证软件系统可信性的一种主要方法．然而，现有的软件完整性验证系统大多需要修改操作系统内核，很难为大规模虚拟机环境中的众多异构系统提供一致解决方案，且无法抵御内核级恶意攻击．针对当前方法在兼容性、安全性以及可管理性上存在的问题，设计并实现了一种在ＶＭＭ层基于系统调用分析技术来验证软件完整性的方法ＶＭＧｕａｒｄ．它通过截获客户操作系统中的系统调用来识别软件加载，并基于系统调用关联性分析和虚拟机文件系统元数据重构技术来验证客户操作系统中软件的完整性．在Ｑｅｍｕ和ＫＶＭ两种主流虚拟化平台上实现了ＶＭＧｕａｒｄ，并通过实验评测ＶＭＧｕａｒｄ的有效性和性能．实验结果表明，ＶＭＧｕａｒｄ能够有效验证客户操作系统中软件的完整性，且性能开销在１０％以内．关键词　云计算；虚拟化；完整性验证；系统调用分析；软件加载中图法分类号　ＴＰ３０９　收稿日期：２０１１－０４－０７；修回日期：２０１１－０６－０９　基金项目：国家自然科学基金项目（９１０１８００４，６０９０３１４９）；国家“九七三”重点基础研究发展计划项目（２０１１ＣＢ３０２６００）；北京航空航天大学科技领航基金项目（ＹＷＦ－１１－０２－０１０） 云计算（ｃｌｏｕｄ　ｃｏｍｐｕｔｉｎｇ）等新型网络计算模式通过有效聚合网络、服务器、存储以及服务等资源，以按需使用（ｏｎ－ｄｅｍａｎｄ）模式实现资源的动态分配，为用户提供简单、透明访问方式以及动态获取大规模计算和存储服务的能力．其中，虚拟化云计算平台采用虚拟化技术实现对底层计算、存储和网络资源的封装，并以虚拟机的形式提供给上层用户．而如何保证其上运行软件的可信性成为影响整个云计算平台安全性的关键．完整性测量和验证技术是确保软件可信性的基本方法，该方法通过对比软件测量指纹识别软件是否被篡改，来验证软件系统的完整性．然而传统软件完整验证方法用于云计算平台软件可信性确保方面存在如下问题：１）兼容性问题．传统软件完整性验证方法大多需要修改操作系统内核（如ＩＭＡ［１］），甚至需要修改或重新编译应用程序（如ＰＲＩＭＡ［２］）．而虚拟化云计算平台承载着大量遗留操作系统和软件，无法被修改或重新编译；另一方面，这些方法需要与特定操作系统绑定，无法对多类型操作系统提供统一支持（例如，ＩＭＡ只能用于Ｌｉｎｕｘ操作系统）．因此，针对虚拟化云计算平台所承载的各类型操作系统和软件，需要提供统一的完整性验证方法．２）安全性问题．传统软件完整性验证方法如Ｔｒｉｐｗｉｒｅ［３］，ＩＭＡ［１］等依赖于操作系统内核的完整性，属于一种弱攻击模型假设，无法抵御内核态攻击，例如ＩＭＡ采用Ｌｉｎｕｘ安全内核机制完成完整性验证功能，需要依赖内核保证验证结果的正确性．因此，对于虚拟化云计算平台的完整性验证方法，需要具有抵御内核攻击的能力．３）可管理性问题．虚拟化云计算平台通过虚拟机技术屏蔽了操作系统异构性，提供对大规模虚拟机的集中式统一管理．然而，现有完整性验证技术由于其实现依赖于特定操作系统，很难对其进行集中管理和升级维护．因此，对于虚拟化云计算平台的完整性验证方法，需要提供一种自动化集中式管理机制．针对上述问题，本文提出了一种基于虚拟监控器（ｖｉｒｔｕａｌ　ｍａｃｈｉｎｅ　ｍｏｎｉｔｏｒ，ＶＭＭ）的软件完整性验证方法ＶＭＧｕａｒｄ，它通过系统调用截获和分析方法对上层操作系统及软件进行完整性验证．然而，在ＶＭＭ层进行软件完整性验证存在一系列技术挑战：第一，在ＶＭＭ层无法直接识别客户操作系统中软件加载行为．当前在ＶＭＭ和客户操作系统内部抽象两者之间存在着语义鸿沟（ｓｅｍａｎｔｉｃ　ｇａｐ），当前主要通过虚拟机自省［４］（ＶＭ　ｉｎｔｒｏｓｐｅｃｔｉｏｎ）技术在ＶＭＭ层获取虚拟机内部信息，但所能获取信息不完整，从而无法满足软件加载期完整性验证需求．例如虚拟机自省技术通过读取内核数据结构来获得进程列表，但此时软件已经处于运行期，攻击者完全可以通过将进程从内核ｔａｓｋ链表移除方法来隐藏进程，从而逃避检测；Ａｎｔｆａｒｍ［５］通过读取ＣＲ３寄存器来识别活动进程，但获取的信息过于底层，缺乏足够的进程上下文信息，很难追溯到软件的可执行代码，因而无法进行完整性验证．第二，在ＶＭＭ层无法直接获取软件路径．由于软件二进制代码会在软件开始运行后按照按需加载（ｐａｇｅ　ｏｎ　ｄｅｍａｎｄ）原则动态加载进内存，因此无法在加载期对软件在内存中的镜像进行完整性验证（此时软件还未真正加载入内存），因此需要通过当前上下文信息回溯找到软件二进制代码在文件系统中的位置．第三，在ＶＭＭ层无法直接提取虚拟机内部文件进行测量．即使定位到软件的文件系统路径，也无法直接对软件作测量，因为从虚拟机监控器层的角度，只能看到虚拟机磁盘镜像，无法获取虚拟机内部的文件系统抽象．针对云计算平台软件完整性验证需求及面临的技术挑战，本文主要贡献如下：１）提出了一种基于ＶＭＭ的软件完整性验证方法ＶＭＧｕａｒｄ．该方法在软件加载期执行完整性验证，不仅实现了对软件实体的完整性测量，还能识别并阻止恶意软件实体对系统完整性的破坏．相比传统验证方法的优势体现在：①无需修改客户操作系统，并解决了异构系统兼容性问题；②避免客户操作系统旁路甚至破坏完整性验证机制，解决了ＶＭＧｕａｒｄ的安全性问题；③提供自动、统一的完整性验证方法，在ＶＭＭ层集中管理，便于升级维护，解决云平台软件完整性验证系统的可管理性问题．２）针对主要技术挑战，提出了３项解决方法：基于系统调用截获的软件加载识别、基于系统调用关联分析的可执行程序定位和文件系统可感知的虚拟机内部文件测量．３项技术均在虚拟机监控器层实现，对上层操作系统透明，适用于各种客户操作系统；同时具有更高的安全性，即使客户操作系统内核被攻破也不影响底层安全机制．３）在２种主流虚拟化平台（ＫＶＭ［６］和Ｑｅｍｕ［７］）上实现了ＶＭＧｕａｒｄ原型系统，并使用恶意软件样本９３４１李　博等：基于ＶＭＭ层系统调用分析的软件完整性验证和标准测试程序评估ＶＭＧｕａｒｄ的有效性和性能．实验结果表明ＶＭＧｕａｒｄ在有效对客户操作系统中的运行软件进行完整性验证的同时，仅带来了不超过１０％的运行时开销．１　ＶＭＧｕａｒｄ系统本节给出ＶＭＧｕａｒｄ的总体架构以及关键技术．１．１　总体架构图１给出了ＶＭＧｕａｒｄ的总体架构．ＶＭＧｕａｒｄ包括２个主要模块：系统调用截获模块和完整性验证模块．其中，系统调用截获模块首先截获客户操作系统中的系统调用事件，从中识别出与可执行程序加载相关的系统调用序列，解析其参数并获得可执行程序在文件系统中的路径，并将路径传给完整性验证模块．完整性验证模块基于接收到的可执行程序路径，结合抽取到的客户文件系统元信息，在虚拟机镜像中读取并测量可执行程序的二进制文件；得到的测量值（通常是Ｈａｓｈ）首先被输出到日志文件，接着与指纹库中的已有指纹比对以验证其完整性，验证结果将为用户提供软件完整性证据．同时，完整性验证模块还可以配置成强安全模式．在该模式下，如果验证结果不匹配，则通过传递错误参数的方式终止当前的系统调用，从而阻止程序的加载运行．Ｆｉｇ．１　Ａｒｃｈｉｔｅｃｔｕｒｅ　ｏｆ　ＶＭＧｕａｒｄ．图１　ＶＭＧｕａｒｄ总体架构１．２　基于系统调用截获的软件加载识别１．２．１　系统调用截获在现代操作系统中，用户程序通过系统调用来访问内核服务．在ｘ８６处理器架构上，当用户程序发起系统调用时，首先会将系统调用参数放入相关寄存器，然后执行中断指令陷入内核．在虚拟化场景下，ＶＭＭ将首先拦截系统调用，具体流程如图２所示．不同虚拟化技术下的系统调用截获技术略有不同．本文实现了二进制翻译和硬件支持虚拟化２种Ｆｉｇ．２　ＶＭＭ－ｌｅｖｅｌ　ｓｙｓｔｅｍ　ｃａｌｌ　ｉｎｔｅｒｃｅｐｔｉｏｎ．图２　ＶＭＭ层系统调用截获平台下的系统调用截获技术．在二进制翻译技术中，虚拟机监控器需要截获上层操作系统执行的敏感指令．因而，在ＶＭＭ运行时，会在执行上层指令前检查所有来自上层操作系统的指令．当检测到敏感指令时，会强制陷入ＶＭＭ层．中断指令（ＩＮＴ）和中断返回指令（ｉＲＥＴ）都是敏感指令，因此可以被ＶＭＭ所截获．针对硬件支持虚拟化平台，我们采用了Ｅｔｈｅｒ［８］中提出的系统调用截获技术．解决问题的关键在于重写系统调用入口指针，使之指向一个非法地址．当系统调用发起时会导致页错误，从而引发ｖｍｅｘｉｔ指令，并发送给ＶＭＭ异常处理模块．我们在该模块中插入完整性验证代码；执行完成后，通过恢复原有的系统调用入口地址来继续正常的执行流程．１．２．２　软件加载识别在截获系统调用后，ＶＭＧｕａｒｄ通过系统调用类型和参数来识别３种可执行程序的加载．可执行程序的加载过程涉及多个系统调用．以Ｌｉｎｕｘ操作系统中的用户应用程序的加载为例，首先操作系统会创建一个新进程，接下来调用ｅｘｅｃｖｅ系统调用服务例程．该系统调用服务例程会在文件系统中找到该程序的可执行文件，并用该文件中描述的上下文信息替换刚创建进程的上下文．当系统调用完成后，将运行在新的上下文中．在这一过程中，ＶＭＧｕａｒｄ会截获所有系统调用，从相应的ｖＣＰＵ寄存器中读取系统调用号，并检查其是否等于ｅｘｅｃｖｅ的系统调用号；如果相等，则说明截获到ｅｘｅｃｖｅ系统调用（系统调用号唯一标识了一个系统调用），从而识别出用户应用程序的加载．类似地，动态链接库和内核模块的加载也可以通过系统调用号匹配的方式来识别．１．３　基于系统调用关联分析的可执行程序定位在识别可执行程序加载后，ＶＭＧｕａｒｄ将定位可执行程序的文件系统路径．通过读取客户虚拟机０４４１计算机研究与发展　２０１１，４８（８）的ｖＣＰＵ上下文以及获取用户堆栈指针可以定位系统调用参数．接着ＶＭＧｕａｒｄ通过这些参数来获取可执行程序路径．获取路径的最佳时机是识别出程序加载的时刻，然而此时的系统调用参数很可能不包含程序的路径信息．例如，ｉｎｉｔ＿ｍｏｄｕｌｅ系统调用标志着内核模块的加载，截获该系统调用得到的参数中不包含内核模块路径，并且由于ＶＭＧｕａｒｄ位于ＶＭＭ层，无法借助任何内核函数和数据结构来获取路径信息．针对这一问题，我们采用“事先记录、事发回溯”的方法．我们注意到在任何可执行程序加载前，首先会通过ｏｐｅｎ系统调用打开．其中，ｏｐｅｎ系统调用的第１个参数就是文件路径．因此，我们首先记录客户操作系统中发生的ｏｐｅｎ系统调用及其参数；当截获到识别可执行程序加载的系统调用时，通过回溯找到打开该程序的ｏｐｅｎ系统调用，并获取路径信息．解决问题的关键在于建立ｏｐｅｎ系统调用和识别程序加载系统调用间的关联关系．首先，ＶＭＧｕａｒｄ需要截获系统调用返回事件，并获得系统调用返回值，因为返回值是２个相互关联的系统调用间的唯一纽带．例如，ｏｐｅｎ系统调用的返回值是文件描述符，该参数将作为ｍｍａｐ系统调用的输入参数．但这里存在一个问题，从ＶＭＭ的角度看，系统调用是并发执行的，也就是说系统调用进入和返回事件是异步的．换句话说，当我们在ＶＭＭ层截获到一个系统调用进入事件，接下来截获到系统调用返回事件，这两者很可能来自于２个不同的系统调用．针对这一问题，我们通过在ＥＩＰ寄存器中存放的当前程序指针来追踪来自同一系统调用的进入和返回事件．当发生系统调用进入时，程序指针（ｉｎｓｔｒｕｃｔｉｏｎ　ｐｏｉｎｔｅｒ）会被操作系统内核保存起来；当系统调用返回时，内核会将保存值加载到ＥＩＰ寄存器，从而恢复程序的继续运行．因此，我们通过程序指针来确定系统调用进入和返回事件是否属于同一个系统调用．然而，这一论断在某些极端情况下并不成立．在现代操作系统中，进程具有自身的独立虚拟地址空间，不同进程在运行中的程序指针有可能相同．因此，基于以上方法可能会导致某个进程的系统调用进入事件错误地匹配到另一个进程的系统调用退出事件．针对这一问题，我们使用ＣＲ３寄存器的值来区分不同进程．在ｘ８６平台上，ＣＲ３寄存器中存储着当前运行进程的页目录表的基地址，因而该值唯一地标识了当前进程．至此，我们获得了系统调用的返回值，接下来将通过该返回值来建立系统调用间的关联关系．以Ｌｉｎｕｘ动态链接库加载为例，我们通过ｏｐｅｎ和ｍｍａｐ两个系统调用来获得动态链接库的路径．其中，参数中指定了ｐｒｏｔ＿ｅｘｅｃ的ｍｍａｐ系统调用标志着动态链接库的加载．由图３所示，在客户操作系统中运行着Ａ和Ｂ两个进程，会并发执行系统调用．细线和粗线分别代表了进程Ａ和进程Ｂ的系统调用执行轨迹．进程Ａ首先引发了ｏｐｅｎ系统调用，接着调用ｍｍａｐ来加载动态链接库．为了在截获ｍｍａｐ系统调用时能获得该动态链接库的文件路径，我们首先截获了ｏｐｅｎ系统调用的进入事件，这时以（ＣＲ３，ＩＰ）为ｋｅｙ，以ｐａｔｈ为ｖａｌｕｅ，存入Ｈａｓｈ．接着截获ｏｐｅｎ系统调用的返回事件，此时以当前ｖＣＰＵ上下文中的ＣＲ３和ＩＰ寄存器值为ｋｅｙ从Ｈａｓｈ表中获取相应的Ｐａｔｈ，并生成新的（ｋｅｙ，ｖａｌｕｅ）对（ｋｅｙ（ＣＲ３，ｆｄ），ｖａｌｕｅ（ｐａｔｈ））存入Ｈａｓｈ表．最后，当我们截获到标志着动态链接库加载的ｍｍａｐ系统调用时，以当前ＣＲ３寄存器值和ｆｄ为ｋｅｙ，从Ｈａｓｈ表中获得对应的值，也就是动态链接库的文件路径．Ｆｉｇ．３　Ｐａｔｈ　ｉｎｆｅｒｒｉｎｇ　ｍｅｔｈｏｄ　ｂｙ　ｓｙｓｔｅｍ　ｃａｌｌ　ｃｏｒｒｅｌａｔｉｏｎ．图３　基于系统调用关联分析的路径获取过程１．４　文件系统可感知的虚拟机内部文件测量技术ＶＭＧｕａｒｄ获得的可执行程序路径位于客户虚拟机中的文件系统．而ＶＭＭ只能观测到虚拟机磁盘镜像文件，无法获得其内部存储的客户文件系统信息，因此无法直接通过路径读取文件．通常的做法是通过在宿主操作系统挂载（ｍｏｕｎｔ）客户文件系统的方式来访问虚拟机内部文件，但这种方式存在以下问题．首先，可读可写的挂载方式会向虚拟磁盘中写入数据，有可能破坏虚拟磁盘和客户文件系统原有的数据结构，甚至导致虚拟机无法正常运行．其次，１４４１李　博等：基于ＶＭＭ层系统调用分析的软件完整性验证若采用只读挂载，虽然不会影响虚拟机的正常运行，但在运行中的虚拟机客户文件系统的修改无法反映到宿主机上挂载的只读文件系统，因而造成不一致状态．针对以上问题，首先ＶＭＧｕａｒｄ通过分析虚拟磁盘中的文件系统布局在ＶＭＭ层重建客户文件系统的元数据（ｍｅｔａｄａｔａ），使ＶＭＧｕａｒｄ能够感知到客户文件系统的内部状态和数据结构；接着以元数据为索引来读取并测量存储于虚拟机磁盘镜像中的可执行文件．由于不同的文件系统在磁盘上布局不尽相同，因此该方法是文件系统相关的，目前只支持Ｅｘｔ２和Ｅｘｔ３两种．两者在Ｌｉｎｕｘ上使用最为广泛，且互相兼容．需要指出的是，本方法不局限于这２种文件系统，只要掌握文件系统的内部结构，就可以使用本方法来重建元数据信息．具体过程如下：首先，ＶＭＧｕａｒｄ通过读取文件系统超级块（ＳｕｐｅｒＢｌｏｃｋ）信息来获取文件系统参数（如ｂｌｏｃｋｓｉｚｅ等），并初始化“文件系统”数据结构；接着，ＶＭＧｕａｒｄ读取文件系统根目录的ｉｎｏｄｅ信息以建立根目录数据结构，并通过ｉｎｏｄｅ中的数据块信息来初始化根目录的“数据块”数据结构；最后，以根目录为起点，通过解析目录文件内容递归建立整个文件系统目录树和其他数据结构．这一过程在虚拟机运行前执行，建立的元数据结构首先会被持久化到宿主机文件系统．当虚拟机即将运行前加载入内存，不影响虚拟机启动和运行时的性能．在客户文件系统元数据重建好后，ＶＭＧｕａｒｄ根据可执行程序名通过搜索文件系统目录树定位到该文件的数据结构，并通过ｉｎｏｄｅ地址指针定位文件的ｉｎｏｄｅ信息，基于ｉｎｏｄｅ信息读取文件数据，并利用ＳＨＡ１算法对程序文件数据进行完整性测量．测量值将被存储到宿主机文件系统的日志文件．完整性测量过程从虚拟机启动开始，在加载内核代码前，ＶＭＧｕａｒｄ首先验证客户操作系统内核文件ｉｎｉｔｒｄ和ｖｍｌｉｎｕｚ的完整性，如果发现篡改会立即终止客户操作系统的运行以确保内核加载的安全性．验证通过后继续测量３种可执行程序．２　系统实现我们在Ｑｅｍｕ和ＫＶＭ两种完全虚拟化平台上实现了ＶＭＧｕａｒｄ的原型系统．目前，ＶＭＧｕａｒｄ已实现对Ｌｉｎｕｘ客户操作系统中的软件进行完整性测量和验证，它可以支持ｘ８６架构下的各版本Ｌｉｎｕｘ内核．ＶＭＧｕａｒｄ并不局限于Ｌｉｎｕｘ客户操作系统，它可以被移植到其他使用系统调用功能的操作系统上．表１给出了Ｌｉｎｕｘ操作系统下与用户应用程序（ｕｓｅｒ　ａｐｐｌｉｃａｔｉｏｎ）、动态链接库（ｓｈａｒｅｄ　ｌｉｂｒａｒｙ）和内核模块（ｋｅｒｎｅｌ　ｍｏｄｕｌｅ）的加载相关的系统调用参数．Ｔａｂｌｅ　１　Ｌｉｎｕｘ　Ｓｙｓｔｅｍ　Ｃａｌｌｓ　ｔｏ　Ｌｏａｄ　ａｎｄ　Ｅｘｅｃｕｔｅ　Ｂｉｎａｒｉｅｓ表１　Ｌｉｎｕｘ操作系统中与软件加载相关的系统调用Ｓｏｆｔｗａｒｅ　Ｔｙｐｅ　Ｓｙｓｔｅｍ　Ｃａｌｌ　Ｎａｍｅ　Ｓｙｓｔｅｍ　Ｃａｌｌ　ＮｕｍｂｅｒＵｓｅｒ　Ａｐｐｌｉｃａｔｉｏｎ　ｅｘｅｃｖｅ　１１Ｓｈａｒｅｄ　Ｌｉｂｒａｒｙｍｍａｐ（ＰＲＯＴ＿ＥＸＥＣ）９０１９２Ｋｅｒｎｅｌ　Ｍｏｄｕｌｅ　ｉｎｉｔ＿ｍｏｄｕｌｅ　１２８２．１　ＶＭＧｕａｒｄ在Ｑｅｍｕ上的实现我们在Ｑｅｍｕ－０．９．１下实现了ＶＭＧｕａｒｄ－Ｑｅｍｕ原型系统．Ｌｉｎｕｘ　２．４及之前版本采用ＩＮＴ　８０ｈ指令来执行系统调用，而Ｌｉｎｕｘ　２．６及之后版本默认使用ｓｙｓｅｎｔｅｒ指令执行系统调用．ＶＭＧｕａｒｄ－Ｑｅｍｕ采用统一的系统调用截获方式，通过禁用Ｑｅｍｕ虚拟ＣＰＵ中ＣＰＵＩＤ的ＳＥＰ　ｂｉｔ，使所有系统调用都通过ＩＮＴ　８０ｈ指令执行．ＶＭＧｕａｒｄ－Ｑｅｍｕ在Ｑｅｍｕ的函数ｄｏ＿ｉｎｔｅｒｒｕｐｔ中插入钩子函数（ｈｏｏｋ）以截获ＩＮＴ　８０ｈ系统调用指令．２．２　ＶＭＧｕａｒｄ在ＫＶＭ上的实现在ＫＶＭ上实现ＶＭＧｕａｒｄ需要ＣＰＵ支持Ｉｎｔｅｌ　ＶＴ硬件虚拟化技术．当前，我们在ＫＶＭ－８４下实现了ＶＭＧｕａｒｄ－ＫＶＭ原型系统．为了截获系统调用，ＶＭＧｕａｒｄ－ＫＶＭ首先在客户操作系统的启动阶段保存ＧＵＥＳＴ＿ＳＹＳＥＮＴＥＲ＿ＥＩＰ寄存器的正常值，并写入一个非法地址．当通过ｓｙｓｅｎｔｅｒ指令执行系统调用时，会首先访问ＧＵＥＳＴ＿ＳＹＳＥＮＴＥＲ＿ＥＩＰ指向的地址，由于该地址已被改写为非法地址，因此会抛出页错误（ｐａｇｅ　ｆａｕｌｔ）异常，并陷入ＫＶＭ虚拟机监控器中．ＶＭＧｕａｒｄ－ＫＶＭ在ＫＶＭ内核模块中插入异常处理代码捕获该异常，同时执行系统调用识别以及完整性验证等操作．验证完成后，ＶＭＧｕａｒｄ－ＫＶＭ将把ＧＵＥＳＴ＿ＳＹＳＥＮＴＥＲ＿ＥＩＰ寄存器恢复为之前的保存值，从而恢复正常的程序执行流程．３　实验及结果分析３．１　ＶＭＧｕａｒｄ系统有效性实验我们执行了４组实验来评价ＶＭＧｕａｒｄ的有效２４４１计算机研究与发展　２０１１，４８（８）性．前３组实验分别用来验证ＶＭＧｕａｒｄ是否能有效识别３种可执行程序的加载并进行完整性验证．１）用户应用程序．我们用ｌｒｋ５，一款Ｌｉｎｕｘ下流行的Ｒｏｏｔｋｉｔ恶意软件，来检验ＶＭＧｕａｒｄ对应用程序完整性测量的有效性．ｌｒｋ５由一组攻击工具集组成，其中ｓｓｈｄ－２．０．１３是一个最新加入的后门程序，它篡改了正常的ｓｓｈｄ程序，用来远程连接被攻击主机并隐藏连接．如图４（ａ）所示，ＶＭＧｕａｒｄ首先发现了该程序的加载，并对其进行了完整性测量，通过与指纹库中已有的指纹进行对比，ＶＭＧｕａｒｄ识别出了该程序的恶意篡改行为．Ｆｉｇ．４　Ｓｃｒｅｅｎｓｈｏｔ　ｏｆ　ＶＭＧｕａｒｄ　ｐｒｏｔｏｔｙｐｅ．图４　ＶＭＧｕａｒｄ原型系统实验截图２）动态链接库．Ｌｉｎｕｘ动态链接库有隐式和显式２种加载方式．我们用Ｌｉｎｕｘ中常用的ｌｓ命令来验证ＶＭＧｕａｒｄ是否能够识别并验证所有在ｌｓ执行过程中隐式加载的动态链接库．如图４（ｂ）所示，ＶＭＧｕａｒｄ共识别出了７个动态链接库的加载，这一结果符合ｌｓ实际调用动态链接库的情况．同时，我们也通过Ｄｌｏｐｅｎ加载动态链接库来验证了ＶＭＧｕａｒｄ对显示加载模式的有效性．３）内核模块．攻击者常利用加载内核模块达到入侵操作系统内核的目的．Ａｄｏｒｅ－ｎｇ是一款著名的内核级恶意软件，我们用它来验证ＶＭＧｕａｒｄ内核模块验证的有效性．为了模拟黑客的攻击行为，我们将Ａｄｏｒｅ－ｎｇ伪装成Ｌｉｎｕｘ　ａｃｐｉ驱动中的ｆａｎ内核模块，并调用ｍｏｄｐｒｏｂｅ命令将其加载入内核．图４（ａ）显示的结果表明ＶＭＧｕａｒｄ检测出对ｆａｎ内核模块的恶意篡改．同时我们编写了测试内核模块ｔｅｓｔ．ｋｏ，由于指纹库中没有该模块的软件指纹，因此ｔｅｓｔ．ｋｏ被标记为“未知”软件．由于ＶＭＧｕａｒｄ对内核模块的加载采用强安全模式，因此本实验中ｔｅｓｔ．ｋｏ被拒绝加载．３．２　ＶＭＧｕａｒｄ系统性能实验我们的硬件测试环境为一台配置为Ｉｎｔｅｌ　Ｄｕｏ２．４ＧＨｚ　ＣＰＵｓ和４ＧＢ内存的ＰＣ．宿主环境运行的操作系统版本为３２ｂ的Ｄｅｂｉａｎ　ｌｅｎｎｙ发行版．对于虚拟机客户操作系统，我们分别测试了包括Ｌｉｎｕｘ　２．４和２．６内核在内的多种Ｌｉｎｕｘ发行版．由于篇幅所限，本文仅给出在Ｌｉｎｕｘ　２．６客户操作系统下的测试结果．测试结果数据均是重复实验的平均值．３．２．１　微基准测试我们采用ｌｍｂｅｎｃｈ作为本次实验的微基准测试集．由于ＶＭＧｕａｒｄ基于系统调用截获和分析技术所实现，为了充分测试ＶＭＧｕａｒｄ的性能开销，我们从ｌｍｂｅｎｃｈ中选择了与系统调用相关基准测试指标．通过分别测试ＶＭＧｕａｒｄ在Ｑｅｍｕ和ＫＶＭ两种实现下的性能指标，并通过与标准Ｑｅｍｕ和ＫＶＭ进行对比来分析ＶＭＧｕａｒｄ所引入的性能开销．表２和表３分别给出了相应的测试结果．Ｔａｂｌｅ　２　Ｍｉｃｒｏｂｅｎｃｈｍａｒｋ　Ｒｅｓｕｌｔｓ　ｏｆ　ＶＭＧｕａｒｄ－Ｑｅｍｕ表２　ＶＭＧｕａｒｄ－Ｑｅｍｕ微基准测试结果μｓＭｉｃｒｏＢｅｎｃｈｍａｒｋｎｕｌｌｏｐｅｎ?ｃｌｏｓｅｒｅａｄ　ｗｒｉｔｅｆｏｒｋ＋ｅｘｅｃｂａｓｈ＋ｅｘｅｃＶａｎｉｌｌａ　Ｑｅｍｕ　０．８６　２０．９　２．３２　１．８４　２　８８５　９　０８７ＶＭＧｕａｒｄ　１．１０　２２．４　２．６６　２．３６　３　０６８　１９　０５５Ｔａｂｌｅ　３　Ｍｉｃｒｏｂｅｎｃｈｍａｒｋ　Ｒｅｓｕｌｔｓ　ｏｆ　ＶＭＧｕａｒｄ－ＫＶＭ表３　ＶＭＧｕａｒｄ－ＫＶＭ微基准测试结果μｓＭｉｃｒｏＢｅｎｃｈｍａｒｋｎｕｌｌｏｐｅｎ?ｃｌｏｓｅｒｅａｄ　ｗｒｉｔｅｆｏｒｋ＋ｅｘｅｃｂａｓｈ＋ｅｘｅｃＶａｎｉｌｌａ　ＫＶＭ　０．１５　１．７３　０．２５　０．２１　２　０６５　５　３１５ＶＭＧｕａｒｄ　５．８２　１４．４７　６．１４　６．０７　２　２７７　１１　３８８ 首先，对比表２和表３中的数据，标准ＫＶＭ下的系统调用处理时间远小于标准Ｑｅｍｕ．这是由于Ｑｅｍｕ需要捕获并模拟所有系统调用指令，而ＫＶＭ在硬件辅助下无需虚拟机监控器的干预，从而避免了频繁切换所带来的性能开销．其次，通过对比表２和表３前２行数据我们发现，对于前４项基准测试指标（ｎｕｌｌ，ｏｐｅｎ，ｒｅａｄ，ｗｒｉｔｅ），ＶＭＧｕａｒｄ－ＫＶＭ相比于ＶＭＧｕａｒｄ－Ｑｅｍｕ引入了更多的性能开销．例如，对于ｏｐｅｎ测试指标，３４４１李　博等：基于ＶＭＭ层系统调用分析的软件完整性验证ＶＭＧｕａｒｄ－Ｑｅｍｕ引入的性能开销为２２．４－２０．９＝１．５μｓ；而ＶＭＧｕａｒｄ－ＫＶＭ引入的性能开销为１４．４７－１．７３＝１２．７４μｓ，远高于ＶＭＧｕａｒｄ－Ｑｅｍｕ的１．５μｓ．这是由于在标准Ｑｅｍｕ中，系统调用指令已经被识别并进行了指令翻译，ＶＭＧｕａｒｄ－Ｑｅｍｕ利用Ｑｅｍｕ已有机制来截获系统调用，因而不会带来较大开销；而在ＶＭＧｕａｒｄ－ＫＶＭ中，需要通过强制引发页错误异常，并由虚拟机监控器捕获的方式来截获系统调用．这一过程中经历了从用户操作系统到ＶＭＭ，以及ＶＭＭ返回用户操作系统内核２次切换，因此开销较大．最后，ＶＭＧｕａｒｄ在ｆｏｒｋ＋ｅｘｅｃ和ｂａｓｈ＋ｅｘｅｃ２项测试指标下的性能开销远大于其他指标．这是因为在这２项指标的测试过程中都需要计算可执行文件的Ｈａｓｈ值．在ｆｏｒｋ＋ｅｘｅｃ测试中执行了ｈｅｌｌｏＷｏｒｌｄ应用程序（６ＫＢ），而在ｂａｓｈ＋ｅｘｅｃ测试分别执行了ｂａｓｈ（７００ＫＢ）和ｈｅｌｌｏＷｏｒｌｄ两个程序．为了进一步研究影响ＶＭＧｕａｒｄ性能开销的因素，我们将ＶＭＧｕａｒｄ执行流程分解为３个步骤：１）系统调用截获；２）程序路径定位；３）程序文件测量；并分别测量各个步骤所引入的性能开销．测试结果如表４所示．ＶＭＧｕａｒｄ主要的性能开销在于测量程序文件的指纹．ｂａｓｈ＋ｅｘｅｃ测试中，ＶＭＧｕａｒｄ－Ｑｅｍｕ执行文件测量所花费的时间几乎是标准Ｑｅｍｕ原始执行时间的１倍（１０５％），而ＶＭＧｕａｒｄ－ＫＶＭ的情况也基本相同（１０２％）．然而，与表３中的数据对比发现，ＶＭＧｕａｒｄ－Ｑｅｍｕ性能开销为１９　０５５－９　０８７＝９　９６８μｓ，几乎是ＶＭＧｕａｒｄ－ＫＶＭ性能开销的２倍．Ｔａｂｌｅ　４　Ｂｒｅａｋｄｏｗｎ　ｏｆ　ＶＭＧｕａｒｄ　Ｏｖｅｒｈｅａｄ表４　ＶＭＧｕａｒｄ性能开销的分解表示％Ｏｖｅｒｈｅａｄｆｏｒｋ＋ｅｘｅｃ　ｂａｓｈ＋ｅｘｅｃＱｅｍｕ　ＫＶＭ　Ｑｅｍｕ　ＫＶＭＳｙｓｔｅｍ　Ｃａｌｌ　Ｉｎｔｅｒｃｅｐｔｉｏｎ　０．７　６．２　０．４　９．０Ｐａｔｈ　Ｉｎｆｅｒｒｉｎｇ　１．７　０．９　４．４　３．２Ｍｅａｓｕｒｅｍｅｎｔｓ（ｈａｓｈ）３．９　３．１　１０５．０　１０２．１ 为此，我们进一步分析了程序文件测量中可能影响性能的因素．首先，２种实现方式下采用完全相同的方法计算文件的Ｈａｓｈ值；其次，测量时需要根据客户文件系统的元数据信息定位到文件数据块，但由于文件路径不深，且索引信息均位于内存中，因而开销基本可以忽略不计；最后，在对文件内容做Ｈａｓｈ前，需要首先将文件内容读入内存，其中涉及多次文件读取操作．通过分析发现，由于ＶＭＧｕａｒｄ－Ｑｅｍｕ是用户态进程，需要通过系统调用来访问文件系统中的文件；而ＶＭＧｕａｒｄ－ＫＶＭ位于内核态执行，可以通过内核函数直接访问文件系统，因此节省了处理时间．３．２．２　应用程序基准测试为了进一步评测ＶＭＧｕａｒｄ的性能，我们采用６种常用应用程序来测试其性能开销，如表５所示：Ｔａｂｌｅ　５　Ａｐｐｌｉｃａｔｉｏｎｓ　ｆｏｒ　Ｅｖａｌｕａｔｉｏｎ表５　基准测试应用程序Ｉｔｅｍ　ＣｏｍｍａｎｄＧｅｔｐｉｄ（２０００ｒｕｎｓ）ｇｅｔｐｉｄ－２０００．ｓｈＤｅｃｏｍｐｒｅｓｓｉｏｎ（ｂｚ２）ｔａｒ　ｚｘｆ　ｌｉｎｕｘ－ｓｏｕｒｃｅ．ｔａｒ．ｂｚ２Ｃｏｍｐｒｅｓｓｉｏｎ（ｇｚ）ｔａｒ　ｚｃｆ　ｌｉｎｕｘ－ｓｏｕｒｃｅ－ｄｉｒＦｉｌｅ　Ｃｏｐｙ　ｃｐ－ｒ　ｌｉｎｕｘ－ｓｏｕｒｃｅ－ｄｉｒ　ｏｔｈｅｒｗｈｅｒｅＫｅｒｎｅｌ　Ｂｕｉｌｄ　ｍａｋｅ　ｄｅｆｃｏｎｆｉｇ　＆ｍａｋｅＬｉｎｕｘ　Ｂｏｏｔ　Ｌｉｎｕｘ　ｂｏｏｔ 图５（ａ）（ｂ）分别给出了ＶＭＧｕａｒｄ－Ｑｅｍｕ和ＶＭＧｕａｒｄ－ＫＶＭ的应用程序基准测试结果．从整体趋势上看，ＶＭＧｕａｒｄ－ＫＶＭ与ＶＭＧｕａｒｄ－Ｑｅｍｕ相比性能开销较大．其原因是ＶＭＧｕａｒｄ－ＫＶＭ需要通过强制触发页错误异常使当前执行流程陷入ＶＭＭ层，来截获上层系统调用，因此一定程度上影响了性能．对于ｇｅｔｐｉｄ测试程序，我们通过重复执行ｇｅｔｐｉｄ程序２　０００次来模拟最坏情况．其中，该程序的唯一操作就是执行ｇｅｔｐｉｄ系统调用，因此与其他测试应用程序相比，ＶＭＧｕａｒｄ所引入的性能开销相对较高．如图５所示，对于压缩和解压缩程序，ＶＭＧｕａｒｄ－Ｑｅｍｕ和ＶＭＧｕａｒｄ－ＫＶＭ分别引入了１．７％和２．７％的性能开销．这２种程序均为计算密集型作业，性能开销较小．文件拷贝是Ｉ?Ｏ密集型作业，其中包含大量的读写操作．而ＶＭＧｕａｒｄ截获了ｗｒｉｔｅ系统调用来防止对加载后软件文件的修改，因此系统开销相对较大．内核编译耗时较长，其中会重复加载少量应用程序和动态链接库，如ｍａｋｅ，ｇｃｃ和ｌｉｂ．ｓｏ等．如图５所示，ＶＭＧｕａｒｄ给内核编译带来的性能开销较小，特别是ＶＭＧｕａｒｄ－Ｑｅｍｕ，其开销基本可以忽略不计．这是由于ＶＭＧｕａｒｄ在完整性验证过程中通过缓存机制避免重复计算可执行文件的Ｈａｓｈ值，从而大大减少了性能开销．Ｌｉｎｕｘ启动可用于全面测试ＶＭＧｕａｒｄ的性能开销，因为Ｌｉｎｕｘ启动过程中会加载ＶＭＧｕａｒｄ验证的全部３种类型的可执行程序．ＶＭＧｕａｒｄ－ＫＶＭ的性能开销接近４４４１计算机研究与发展　２０１１，４８（８）。

基于SystemC和SystemVerilog的联合仿真平台设计卢艳君【摘要】采用SystemC建模高抽象级模型、SystemVerilog进行验证工作,是解决验证工作量随着SoC复杂度提高而增加问题的有效手段.为了实现两种语言的联合仿真,提出了一种基于SystemC和SystemVerilog的联合仿真平台的实现,平台采用UVM验证方法学,采用标准化的组件结构与TLM通信方案,采用官方的UVMC库解决了SystemC与SystemVerilog之间的数据通讯问题,能够产生定向或约束性的随机激励.实际在UVM验证平台中完成对于AHB主设备接口的验证,结果显示,所设计的平台可以行之有效地实现联合仿真.【期刊名称】《黑龙江科技信息》【年(卷),期】2017(000)027【总页数】3页(P16-18)【关键词】SystemVerilog;SystemC;UVMC;联合仿真【作者】卢艳君【作者单位】广州民航职业技术学院,广东广州 510403【正文语种】中文随着SoC技术的不断发展，设计的复杂程度不断提高，并且新型的IP核设计流程、软件件协同仿真等机制的出现，使得IC的验证复杂度大大增加，验证已经占用整个IC开发流程的70%左右[1]。

针对IC行业发展的问题，新型的硬件描述与验证语言得以应用，使用SystemC语言进行硬件建模，同时基于SystemVerilog进行验证工作的方案越来越流行，其中SystemC可以提供事务级、高抽象度的建模方法，而应用SystemVerilog可以利用灵活的机制以及强大的进行规范而全面的验证，各自具有其独有的特点，两种语言二者结合起来，可以提高效率，缩短开发时间、增强验证效果。

然而，两种语言之间存在数据以及控制通信的障碍，因此如何解决二者的适配问题至关重要。

针对这一问题，本文提出了一种基于UVMC的联合仿真平台实现，能够很好的解决两者的适配问题。

SystemVerilog与SystemC之间适配的实现，其根本是缘于硬件描述语言（HDL，Hardware Description Language）与软/硬件协同设计语言（S/HCD，Software/Hardware Co-Design）之间的语法等效性。

基于SystemC的系统验证研究和应用
李振;王伟
【期刊名称】《微计算机信息》
【年(卷),期】2008(024)023
【摘要】视频编解码芯片中运动估计与补偿单元(MECU)的算法复杂,使用传统硬件描述语言建立模型和模型验证的过程繁琐耗时,为了缩短芯片验证时间,本文针对MECU模块提出了基于SystemC语言的具体系统级验证流程.在整个芯片验证工作中,为了实现MECU模块和低抽象级的其它外部模块协同验证,本文提出的验证流程利用了SystemC能在不同抽象级建模的优势,时MECU模块的数据传输控制端口进行细化.仿真结果表明:与使用传统件描述语言验证方法相比,基于SystemC的验证流程简单有效,大大缩短了建模与验证时间.
【总页数】3页(P146-148)
【作者】李振;王伟
【作者单位】200240,上海交通大学自动化系;200240,上海交通大学自动化系【正文语种】中文
【中图分类】TN402
【相关文献】
1.基于GAMP5的我国制药企业计算机化系统验证的应用研究 [J], 秦垚;梁毅
2.基于SystemC的功能模型的建模和验证技术研究 [J], 贺明月;彭德生
3.设计模式在基于SystemC的指令译码模块设计中的应用 [J], 任志清;吴悦;杨洪
斌
4.基于UML-SystemC的纹理映射建模方法研究 [J], 魏美荣;田泽;吴晓成;韩立敏
5.基于GAMP5的我国制药企业计算机化系统验证的应用研究 [J], 秦垚;梁毅因版权原因，仅展示原文概要，查看原文内容请购买。

基于VMM方法的SOC集成验证李磊;罗胜钦【摘要】随着集成电路规模和设计复杂度的快速增长,芯片验证的难度也不断加大,芯片验证的工作量达到了整个芯片研发的70%,已然成为缩短芯片上市时间的瓶颈.VMM是synopsys公司推出的基于systemverilog的一套验证方法学,已经成为SOC验证的主流方法学.SOC系统采用ARM9处理器和DSP处理器,基于AMBA总线架构.SOC验证包括集成验证和系统验证,相对于系统验证,集成验证具有运行速度快的特点,在芯片验证中极其重要.文中结合项目来介绍SOC集成验证,运用业界主流的VMM验证方法学并结合DesignWare VIP来搭建集成验证环境,通过VMM类的介绍来说明验证的过程,并提出验证环境归一化的思想.【期刊名称】《电子与封装》【年(卷),期】2011(011)001【总页数】4页(P18-21)【关键词】VMM验证;SystemVerilog;DesignWare VIP;系统芯片【作者】李磊;罗胜钦【作者单位】同济大学电子科学与技术系,上海,201804;同济大学电子科学与技术系,上海,201804【正文语种】中文【中图分类】TN4021 引言随着集成电路设计向超大规模发展，芯片验证工作的难度在不断增大，验证的工作量已经占到整个SOC研发的70%左右，芯片验证直接影响到芯片上市的时间，因此提高芯片验证的效率已变得至关重要[1]。

VMM是synopsys公司推出的基于system verilog的一套验证方法学，继承于RVM。

利用VMM的层次化、随机约束等特点，能有效提升现有的验证方法，快速搭建具有目标模块的验证环境[2]。

2 SOC集成验证SOC验证可以分为集成验证IV（Integrated Verification）和系统验证SV （System Verification）。

本文主要介绍SOC集成验证，采用VMM验证方法学和DesignWare VIP，Master例化为VIP Interface模型，通过约束VIP Transaction参数产生各种定向激励；通过约束Scenario Class产生各种随机激励。

基于ＶＭＭ的ＡＳＩＣ建模验证摘要：随着数字集成电路设计越来越复杂,验证的难度也越来越大。

根据完成的一款分组传送以太网交换芯片的项目总结验证的经验，提出了一种基于VMM验证平台的行为级建模的验证方法。

项目的验证结果表明，这种验证方法可以方便地进行RTL和参考模型的联合仿真，并采用分层的验证环境，能最大限度地提高验证效率和覆盖率，有效地减少验证工作量和缩短验证时间。

关键词：VMM；SystemVerilog；ASIC；参考模型；验证1引言随着集成电路设计向大规模和超大规模发展，芯片验证已成为了ASIC研发的瓶颈。

目前流行的验证方法主要有仿真验证和FPGA验证。

仿真验证由于其施加的激励具有可控性，所以测试的覆盖率广、监测点多和便于观察内部RTL的信号，其缺点是仿真速度比较慢。

FPGA验证在一定程度上可以弥补仿真验证速度慢的缺点，但是定位问题和解决问题仍然需要仿真验证进一步分析RTL代码，因此ASIC验证通常以仿真验证为主要的验证手段。

面对复杂度逐渐提高、规模逐渐增大的挑战，国内外大多数ASIC设计公司开始采用设计与验证分离的方法进行ASIC研发，建立专业的验证团队保证芯片功能的正确性。

专业的验证团队采用功能行为模型与设计工程师编写的RTL代码联合仿真，进行自动检测，同时进行覆盖率收集分析。

此方法降低了定位验证问题的难度、提高了验证效率和可靠性。

2VMM验证平台VMM（Verification Methodology Manual for SystemVerilog）是Synopsys公司推行的基于SystemVerilog的验证平台，提供了验证平台的基本架构，包括激励产生、事务处理、覆盖率收集、基本环境等。

这些都是以基本类（class）的形式存放在vmm.sv库中，在搭建验证环境时需要根据实际项目验证环境的需求调用VMM库中的基本类，然后作相应的扩展实现所需要的功能。

常用的基本类：(1)vmm_data，所有事务描述符和数据模型的基础，提供仿真激励基本的操作，常用操作方法有copy、copy_data、compare等；(2)vmm_channel,事务的接口机制，可以在各个事务间传递vmm_data数据，在VMM验证平台_channel操作可以直接实现通道传递数据激励，常用操作方法有put、get、sneak、is_full等；(3)vmm_xactor，所有事务处理的基础，包括总线功能模型、监视器、发生器，提供了一套标准的控制机制，功能覆盖率也包含在此基本类中，常用的操作方法有new、prepend_callback、append_callback、start_xactor、stop_xactor、reset_xactor、wait_if_stoped、main等，整个事务在main中运行；(4)vmm_env，实现验证环境的基本类，采用九步顺序执行机制gen_cfg、build、reset_dut、cfg_dut、start、wait_for_end、stop、clea-nup、report，所有事务都在vmm_env生成实例并且将实例按照验证模型连接，通过vmm_env执行。

vmm验证方法学VMM验证方法学引言：虚拟机监控器（Virtual Machine Monitor，VMM）是一种关键的系统软件，用于在物理硬件上运行多个虚拟机实例。

为了确保VMM的正确性和可靠性，验证VMM的正确性成为一项重要的研究课题。

本文将介绍一种VMM验证方法学，以确保VMM的正确性和安全性。

一、VMM验证的重要性VMM作为系统软件的核心，负责管理和控制虚拟机实例的运行。

如果VMM存在错误或漏洞，可能造成整个系统的崩溃或数据泄露。

因此，验证VMM的正确性对于确保系统的稳定性和安全性至关重要。

二、VMM验证的挑战由于VMM的复杂性和庞大性，验证VMM的正确性是一项具有挑战性的任务。

首先，VMM的代码规模通常非常庞大，很难手动分析和测试所有可能的执行路径。

其次，VMM需要与底层硬件和多个虚拟机实例交互，使得验证过程更加复杂。

因此，需要一种有效的验证方法学来解决这些挑战。

三、基于模型检测的方法模型检测是一种常用的形式化验证方法，可以自动地验证系统模型是否满足指定的性质。

在VMM验证中，可以将VMM建模成一个状态机模型，然后使用模型检测工具对其进行验证。

通过定义正确性属性，例如VMM应满足的安全性、一致性和可用性等属性，可以使用模型检测工具自动验证这些属性是否满足。

四、符号执行的方法符号执行是一种基于约束求解的自动化验证方法，它通过对程序中的符号变量进行符号计算，生成约束条件，并使用约束求解器求解这些约束条件。

在VMM验证中，可以使用符号执行技术对VMM 进行验证。

符号执行可以遍历所有可能的输入路径，从而检测出潜在的错误或漏洞。

五、随机化的方法随机化是一种基于随机选择的验证方法，它通过随机生成测试用例来发现系统中的错误。

在VMM验证中，可以使用随机化的方法来发现VMM中的错误或漏洞。

通过随机生成各种输入和操作序列，可以观察VMM的行为，并检测出潜在的错误。

六、形式化验证的方法形式化验证是一种基于数学方法的验证技术，它通过使用数学语言和逻辑推理来验证系统的正确性。

基于VMM的ALU验证苏雪;潘明;翟江涛【摘要】基于VMM方法学设计和实现了一个随机验证环境，验证一个64位ALU。

该验证环境具备一套功能完备的随机测试程序发生器，可以生成覆盖率指导的有约束的定点、浮点指令序列，调用一个由C语言实现的参考模型进行运算结果自检，并采用覆盖率收敛技术实现覆盖率快速收敛。

实践结果表明，设计的随机验证环境，能够高效验证ALU的各项逻辑功能，减少测试时间，且随机测试程序生成模块可以简单移植应用于处理器其他模块的功能验证。

%A randomtest⁃bench was designed and completed on the basis of VMM to verify a 64⁃bit ALU. The test⁃bench has a coverage directed random test program generator and can generate different kinds of flexed point and floating point instruc⁃tion arrays,which a reference model realized by C language can be called to check out the operation results automatically,and can implement the rapid convergence of coverage rate by coverage convergence technology. The practice results show that the test⁃bench can verify each ALU logic function effectively,shorten the verification time,and test the module randomly generated by program,and can be used in other processor module function verification by simple transplantation.【期刊名称】《现代电子技术》【年(卷),期】2015(000)007【总页数】4页(P144-147)【关键词】SystemVerilog;VMM;验证;算数逻辑单元【作者】苏雪;潘明;翟江涛【作者单位】桂林电子科技大学电子工程及自动化学院，广西桂林 541004;桂林电子科技大学电子工程及自动化学院，广西桂林 541004;桂林电子科技大学电子工程及自动化学院，广西桂林 541004【正文语种】中文【中图分类】TN407-34随着高性能处理器设计日趋复杂，如何对处理器各设计模块进行有效而充分的验证，是芯片设计成功的关键因素之一[1]。