虚拟机陷出的检测及分析

合集下载

软件测试与质量保证教程

软件测试与质量保证教程

软件测试与质量保证教程第1章软件测试基础 (5)1.1 软件测试的定义与目的 (5)1.2 软件测试与软件开发过程 (5)1.3 软件测试的生命周期 (5)第2章软件测试类型与层次 (5)2.1 单元测试 (5)2.2 集成测试 (5)2.3 系统测试 (5)2.4 验收测试 (5)第3章测试用例设计 (5)3.1 测试用例的基本概念 (5)3.2 黑盒测试用例设计方法 (5)3.3 白盒测试用例设计方法 (5)第4章缺陷管理 (5)4.1 缺陷报告 (5)4.2 缺陷生命周期 (5)4.3 缺陷分析 (6)第5章自动化测试 (6)5.1 自动化测试概述 (6)5.2 自动化测试工具 (6)5.3 自动化测试用例设计 (6)第6章功能测试 (6)6.1 功能测试基础 (6)6.2 功能测试工具 (6)6.3 功能瓶颈分析 (6)第7章软件质量保证 (6)7.1 质量保证的基本概念 (6)7.2 质量保证与软件过程改进 (6)7.3 质量保证体系 (6)第8章评审与审计 (6)8.1 代码审查 (6)8.2 设计审查 (6)8.3 测试审查 (6)第9章测试团队与项目管理 (6)9.1 测试团队组织结构 (6)9.2 测试团队协作 (6)9.3 测试项目管理 (6)第10章敏捷测试 (6)10.1 敏捷测试概述 (6)10.2 敏捷测试实践 (6)10.3 敏捷测试工具 (6)第11章安全测试 (6)11.1 安全测试基础 (6)11.2 常见安全漏洞分析 (6)11.3 安全测试工具 (6)第12章测试前沿技术 (7)12.1 人工智能与机器学习在测试中的应用 (7)12.2 虚拟现实与增强现实测试 (7)12.3 物联网测试技术展望 (7)第1章软件测试基础 (7)1.1 软件测试的定义与目的 (7)1.2 软件测试与软件开发过程 (7)1.3 软件测试的生命周期 (7)第2章软件测试类型与层次 (8)2.1 单元测试 (8)2.2 集成测试 (8)2.3 系统测试 (8)2.4 验收测试 (8)第3章测试用例设计 (9)3.1 测试用例的基本概念 (9)3.2 黑盒测试用例设计方法 (9)3.3 白盒测试用例设计方法 (9)第4章缺陷管理 (10)4.1 缺陷报告 (10)4.1.1 缺陷基本信息 (10)4.1.2 缺陷描述 (10)4.1.3 缺陷相关附件 (10)4.2 缺陷生命周期 (10)4.2.1 发觉(Open) (11)4.2.2 确认(Confirmed) (11)4.2.3 解决(Fixed) (11)4.2.4 验证(Verified) (11)4.2.5 关闭(Closed) (11)4.3 缺陷分析 (11)4.3.1 缺陷分布分析 (11)4.3.2 缺陷原因分析 (11)4.3.3 缺陷趋势分析 (11)4.3.4 缺陷预防措施 (11)第5章自动化测试 (11)5.1 自动化测试概述 (12)5.1.1 定义 (12)5.1.2 分类 (12)5.1.3 原理 (12)5.1.4 优势 (12)5.2 自动化测试工具 (12)5.2.2 Appium (13)5.2.3 JMeter (13)5.3 自动化测试用例设计 (13)5.3.1 等价类划分法 (13)5.3.2 边界值分析法 (13)5.3.3 错误推测法 (13)5.3.4 判定表法 (13)5.3.5 关键字驱动法 (13)5.3.6 页面对象模型(POM) (13)第6章功能测试 (14)6.1 功能测试基础 (14)6.2 功能测试工具 (14)6.3 功能瓶颈分析 (14)第7章软件质量保证 (15)7.1 质量保证的基本概念 (15)7.1.1 质量 (15)7.1.2 软件质量 (16)7.1.3 质量保证的定义 (16)7.1.4 质量保证的目标和原则 (16)7.2 质量保证与软件过程改进 (16)7.2.1 软件过程改进的概念 (16)7.2.2 软件过程改进的方法 (17)7.2.3 质量保证与软件过程改进的关系 (17)7.3 质量保证体系 (17)7.3.1 质量保证体系的构成 (17)7.3.2 质量保证体系的实施要点 (17)第8章评审与审计 (18)8.1 代码审查 (18)8.1.1 目的 (18)8.1.2 方法 (18)8.1.3 输出 (18)8.2 设计审查 (18)8.2.1 目的 (18)8.2.2 方法 (18)8.2.3 输出 (19)8.3 测试审查 (19)8.3.1 目的 (19)8.3.2 方法 (19)8.3.3 输出 (19)第9章测试团队与项目管理 (19)9.1 测试团队组织结构 (19)9.1.1 测试管理层 (19)9.1.2 功能测试组 (19)9.1.4 自动化测试组 (20)9.1.5 安全测试组 (20)9.2 测试团队协作 (20)9.2.1 明确角色和职责 (20)9.2.2 沟通与协作 (20)9.2.3 共享资源 (20)9.2.4 跨部门协作 (20)9.3 测试项目管理 (20)9.3.1 测试计划 (20)9.3.2 测试用例管理 (20)9.3.3 缺陷管理 (20)9.3.4 风险管理 (21)9.3.5 测试报告 (21)第10章敏捷测试 (21)10.1 敏捷测试概述 (21)10.1.1 敏捷测试基本概念 (21)10.1.2 敏捷测试原则 (21)10.1.3 敏捷测试的优势 (21)10.2 敏捷测试实践 (22)10.2.1 测试计划 (22)10.2.2 测试设计 (22)10.2.3 测试执行 (22)10.2.4 测试反馈 (23)10.2.5 测试改进 (23)10.3 敏捷测试工具 (23)10.3.1 JIRA (23)10.3.2 Selenium (23)10.3.3 JMeter (24)10.3.4 Allure (24)第11章安全测试 (24)11.1 安全测试基础 (24)11.1.1 安全测试概念 (24)11.1.2 安全测试目标 (24)11.1.3 安全测试原则 (25)11.1.4 安全测试方法 (25)11.2 常见安全漏洞分析 (25)11.2.1 SQL注入 (25)11.2.2 跨站脚本攻击(XSS) (25)11.2.3 跨站请求伪造(CSRF) (25)11.2.4 其他常见漏洞 (25)11.3 安全测试工具 (26)11.3.1 静态代码分析工具 (26)11.3.2 动态测试工具 (26)11.3.4 模糊测试工具 (26)第12章测试前沿技术 (26)12.1 人工智能与机器学习在测试中的应用 (26)12.1.1 智能化测试用例 (26)12.1.2 智能化缺陷定位 (26)12.1.3 智能化测试评估 (27)12.2 虚拟现实与增强现实测试 (27)12.2.1 VR/AR设备兼容性测试 (27)12.2.2 VR/AR功能测试 (27)12.2.3 VR/AR用户体验测试 (27)12.3 物联网测试技术展望 (27)12.3.1 设备互联测试 (27)12.3.2 网络安全性测试 (27)12.3.3 数据处理与分析测试 (27)好的,以下是一份软件测试与质量保证教程的目录:第1章软件测试基础1.1 软件测试的定义与目的1.2 软件测试与软件开发过程1.3 软件测试的生命周期第2章软件测试类型与层次2.1 单元测试2.2 集成测试2.3 系统测试2.4 验收测试第3章测试用例设计3.1 测试用例的基本概念3.2 黑盒测试用例设计方法3.3 白盒测试用例设计方法第4章缺陷管理4.1 缺陷报告4.2 缺陷生命周期4.3 缺陷分析第5章自动化测试5.1 自动化测试概述5.2 自动化测试工具5.3 自动化测试用例设计第6章功能测试6.1 功能测试基础6.2 功能测试工具6.3 功能瓶颈分析第7章软件质量保证7.1 质量保证的基本概念7.2 质量保证与软件过程改进7.3 质量保证体系第8章评审与审计8.1 代码审查8.2 设计审查8.3 测试审查第9章测试团队与项目管理9.1 测试团队组织结构9.2 测试团队协作9.3 测试项目管理第10章敏捷测试10.1 敏捷测试概述10.2 敏捷测试实践10.3 敏捷测试工具第11章安全测试11.1 安全测试基础11.2 常见安全漏洞分析11.3 安全测试工具第12章测试前沿技术12.1 人工智能与机器学习在测试中的应用12.2 虚拟现实与增强现实测试12.3 物联网测试技术展望第1章软件测试基础1.1 软件测试的定义与目的软件测试是通过对软件产品进行操作和评价,以验证软件是否满足预定的需求和设计,查找并排除其中潜在缺陷和错误的过程。

云计算中虚拟机安全评估

云计算中虚拟机安全评估

云计算中虚拟机的安全评估Aleksandar Donevski, Sasko Ristov and Marjan GusevSs. Cyril and Methodius University,Faculty of Information Sciences and Computer Engineering,Skopje, MacedoniaEmail: aleksandar.donevski@, sashko.ristov@im.mk,marjan.gushev@im.mk摘要——一个公司的安全边界是如果虚拟机迁移到云的前提下受损。

尽管云服务提供商(CSP)迁移的虚拟机提供了一定的保障水平,主要是从外部云,但是云服务消费者现在正受到新兴的挑战,由于多租户模式,即受到其他合租托管的虚拟机主机的威胁。

CSP也面临着云租户的威胁。

CSP和租户都可能因云的脆弱性而受到拖累。

这篇论文中我们分析由其他租户和外部云造成的虚拟机安全威胁。

同时,我们比较最常见的开源云提供给特定虚拟机的安全水平。

虚拟机的安全评估在不同的操作系统上实现。

关键词:云计算,OpenStack云,安全评估,虚拟化。

1.介绍云计算市场持续增长,为客户提供各式各样的功能。

例如,客户可以将他们的数据、虚拟机或备份数据外包给存储空间无限大的云。

无论他们使用的是什么类型的云和调度模型,云服务提供商必须保证访问控制权和确保删除。

一种可能的解决方法就是将安全作为一种服务来实现和维持对云的保护,从而满足客户提出的安全水平。

云中的虚拟机实例应当不仅能防御外部的攻击,同时也要抵抗合租的租户,无论他们是来自相同的云中的物理机还是不同的云。

除了传统的性能/成本效益的资源消耗,电信运营商也应该包括在虚拟机配置由客户指定的安全要求。

选择一个私有云提供了一种可能性来控制系统的安全性,但它缺乏可扩展性和弹性特征。

从一方面来说,公共云的使用提供了高扩展性和弹性,但从另一个方面是受安全由于大部分的控制已经转移到CSP。

虚拟安全隐患排查(3篇)

虚拟安全隐患排查(3篇)

第1篇随着信息技术的飞速发展,虚拟化技术在企业、政府、教育等领域的应用越来越广泛。

虚拟化技术通过将物理服务器、存储和网络设备虚拟化,提高了资源利用率,降低了运维成本,但同时也带来了新的安全隐患。

为了确保虚拟化环境的稳定和安全,本文将针对虚拟安全隐患进行排查,并提出相应的解决方案。

一、虚拟安全隐患概述1. 虚拟机逃逸虚拟机逃逸是指虚拟机突破虚拟化平台的限制,获取宿主机的权限。

一旦虚拟机逃逸成功,攻击者可以控制整个宿主机,进而对整个虚拟化环境造成严重威胁。

2. 虚拟化平台漏洞虚拟化平台是虚拟化环境的核心,其安全性直接影响到整个虚拟化环境的安全。

虚拟化平台漏洞可能导致攻击者获取管理员权限,控制虚拟化平台,进而攻击虚拟机。

3. 虚拟机配置不当虚拟机配置不当可能导致虚拟机存在安全隐患,如默认密码、不安全的端口等。

这些配置问题可能被攻击者利用,攻击虚拟机。

4. 网络隔离失效虚拟化环境中,网络隔离是保障安全的重要手段。

如果网络隔离失效,攻击者可能通过虚拟机之间进行横向攻击,威胁整个虚拟化环境。

5. 数据泄露虚拟化环境中,数据泄露可能导致敏感信息泄露,给企业带来严重的经济损失和信誉损失。

二、虚拟安全隐患排查方法1. 虚拟机逃逸排查(1)检查虚拟机权限:确保虚拟机用户权限合理,避免使用默认密码。

(2)关闭不必要的端口:关闭虚拟机中不必要的端口,减少攻击面。

(3)定期更新虚拟机:及时更新虚拟机操作系统和应用程序,修复已知漏洞。

(4)隔离虚拟机:将关键业务虚拟机与其他虚拟机隔离,降低攻击风险。

2. 虚拟化平台漏洞排查(1)定期更新虚拟化平台:及时更新虚拟化平台,修复已知漏洞。

(2)启用安全功能:开启虚拟化平台的安全功能,如虚拟化扩展程序、安全启动等。

(3)限制管理员权限:严格控制虚拟化平台管理员权限,避免权限滥用。

(4)定期进行安全审计:对虚拟化平台进行安全审计,发现潜在漏洞。

3. 虚拟机配置不当排查(1)检查虚拟机默认密码:修改虚拟机默认密码,避免密码泄露。

虚拟化平台安全问题分析及优化

虚拟化平台安全问题分析及优化

虚拟化平台安全问题分析及优化作者:黎佳来源:《计算机与网络》2020年第18期当前虚拟化平台处于快速发展中,但同时安全问题也同步上升,成为网络安全领域亟待解决的关键问题。

主流虚拟化平台虽然具有多方面的优势,但只有不断提高安全性,才能保证云计算的发展。

对于虚拟化平台的安全问题,原有的安全解决方案难以实现,主流虚拟化平台,要明确当前所面临的各种安全风险,结合安全漏洞类型提出相关应对措施。

云计算改变了网络服务模式,在云计算条件下,用户对于数据的处理不再依赖硬件资源,而是借助服务器实现集中计算,不同用户可以处于隔离条件下,拥有安全、可信的服务环境。

虚拟化技术是当前云计算发展的主要方向之一,其架构形式如图1所示。

随着技术的普及,虚拟化平台的安全问题也更加突出,其危害程度与影响范围远高于传统模式下的单机。

分析主流虚拟化平台存在的安全问题并采取优势措施,有利于为云计算的稳定发展创造条件。

流虚拟化平台的安全问题分类虚拟化平台引发的安全风险虚拟化平台存在的安全风险,是由于自身有难以避免的安全漏洞存在。

不法分子出于利益原因利用平台漏洞,借助虚拟化网络对平台的接口展开攻击,导致虚拟化平台上的用户信息发生泄露。

由于我国技术的局限性,平台的核心技术大多源于国外的内核,虚拟化平台的基础被国外的少数厂商垄断,导致虚拟化平台在构建时可控性差,难以有效部署安全措施,难以判别引入的平台技术是否被厂商留有控制“后门”,可信度难以保证。

在虚拟化平台上,不同虚拟主机的资源共享或数据交换需要通过虚拟资源池,因此资源存在被恶意抢占的风险,难以保证安全利用,平台的服务会伴随风险。

虚拟化网络存在的安全风险虚拟化的网络结构不同于传统的网络,原有的防护模式难以应对风险。

在云计算下,资源池内存在大量的虚拟化资源,可以结合数据的需要对资源加以调配。

在这种模式下,原有的安全防护方式不能保证虚拟化平台的安全,难以应对恶意代码的攻击以及协议审计等安全威胁。

在虚拟化条件下,为了有效调整负载,虚拟化平台采用了动态漂移技术,这导致传統的虚拟化主机位置有了变化,边界防护策略也要改变。

虚拟机软件的漏洞和虚拟机执行环境的检测与反检测漏洞预警-电脑资料

虚拟机软件的漏洞和虚拟机执行环境的检测与反检测漏洞预警-电脑资料

虚拟机软件的漏洞和虚拟机执行环境的检测与反检测漏洞预警-电脑资料1、最近发生的关于虚拟机软件的漏洞VM产品的漏洞有一些特殊性,涉及到几个操作环境,比如有主操作系统、客操作系统,还有一个比较特殊的是它的虚拟机管理器里面也可能有漏洞,。

我列出了大概五种可以产生漏洞的地方。

首先是VMM本身可能有漏洞,我列出了三个。

其中有一个是比较新的,是在x64系统模拟上VMM存在漏洞,这使Guest OS可以提升本地权限。

当然在Guest OS里面也可能有漏洞,一个比较典型的案例就是CVE-2007-5671,这个就是利用在客操作系统里面安装的一个驱动程序HGFS.sys,这个HGFS使主操作系统和客操作系统可以共享文件和目录。

它里面存在一个漏洞,这个漏洞是驱动上是非常常见的,对IO ctl提供的参数没有进行足够的验证,导致从用户态能够读写任意的内存地址。

这也是本地提权非常典型的一个案例。

现在我个人觉得,像这种利用驱动IO ctl来提权的情况发生的比较多。

原因是因为有很多IO ctl fuzz工具的产生,可以向一个驱动设备任意地发送IO ctl,并且变换它的参数。

如果发现机器蓝屏了,你就会觉得有可能这是可以利用的漏洞,它比较好找,发生的原因也比较简单,一般都是用户态传进来的参数,内核态可能直接拿参数里面的一个地址进行读写,而没有验证参数的合法性。

比较好分析漏洞的成因,所以数量就比较多。

当然在HOST OS里也存在比较多的漏洞,我列出了两个是我自己发现并上报给VMware的,是在Host OS中进行本地提权的两个漏洞。

如果一会儿还有时间,我会讲一下。

另外一个比较有趣的,也是比较独特的类型,是从客操作系统向主操作系统的逃逸。

比如说在Windows里执行Linux代码,可以从Linux VM里面渗透出来,在Windows主操作系统环境里面执行代码,这就叫做VM逃逸。

最近比较常见的就是我列出的三个,一个HGFS 堆溢出,一个是HGFS共享目录遍历漏洞,还有一个是通过RPC的调用。

H3C CAS主机性能缓慢问题排查

H3C CAS主机性能缓慢问题排查

版权所有:杭州华三通信技术有限公司H3CCAS主机性能缓慢问题排查一、H3C CAS 虚拟机暂停问题排查在虚拟化环境中出现“性能”问题时,一般需要从“应用”、“虚拟机”和“虚拟化平台”三个方面来分析。

“应用”方面有可能是用户编写的代码问题导致程序运行缓慢,也有可能是“中间件”的配置问题导致WEB 页面响应时间过长,还有可能是数据库的查询脚本未优化导致查询超时,因此,“应用”方面导致的性能缓慢问题主要由用户来主导定位。

而“虚拟机”和“虚拟化平台”方面主要是由于系统资源不足导致的。

系统资源主要包括了CPU、内存以及磁盘,它们是系统稳定运行的基础。

过度使用这些资源的任何一种都会使系统陷入困境,严重的话还会出现系统崩溃的风险。

图1:top命令输出信息在这三个系统资源中最核心的是CPU资源,它是主机的大脑。

CPU资源的使用情况可以通过top工具来查看。

在主机的后台命令行输入top命令后,马上可以看到大量的系统信息。

第三行显示了CPU资源运行状况的信息。

最能体现主机当前性能的指标是“us”、“sy”、“id”和“wa”。

图2:CPU指标 1)“us”是用户CPU时间:表示用户进程所占CPU时间的百分比;2)“sy”是系统CPU时间:表示运行内核所占CPU时间的百分比;3)“id”是CPU的空闲时间百分比;4)“wa”是I/O等待时间:表示CPU时间用在等待执行I/O操作所占的百分比。

当CPU资源、内存资源或者磁盘资源不足导致性能缓慢时都会体现到CPU的指标项中。

本文对此类问题的排查方法给出详细的说明,供现场工程师参考1、CPU资源是否异常在top命令输出的信息中会看到较高的用户CPU时间百分比,如下面显示的用户CPU 时间百分比已经高达99.6%,说明CPU资源被用户进程大量占用。

版权所有:杭州华三通信技术有限公司版权所有:杭州华三通信技术有限公司图3:CPU 异常信息2、检查CPU 资源我们需要分析是哪些进程占用了这么多的CPU 资源,查看方法也比较简单,因为top 命令的输出信息中还包括了进程占用CPU 资源信息统计,并且默认是以CPU 来进行排序的,因此只需要查看排在前面的是哪些进程,就可以确定是哪些进程占用了大量的CPU 资源。

浪潮服务器故障问题报告分析

浪潮服务器故障问题报告分析

故障问题分析报告⼀、故障概述时间:2024年9⽉24⽇22:06主机:192.168.x.x 问题现象:存储池 A 和 B 未挂载,导致部分虚拟机⽆法访问其存储资源。

CPU 使⽤率 99.5%,内存占⽤率达到 84%。

⽆法通过 SSH 、KVM 和 BMC 远程连接节点。

其他 ⼏ 个节点运⾏正常,磁盘阵列⽆报警。

通过 ping 可以连接节点,但远程管理⼯具⽆法访问。

⼆、故障现象详细分析1. 存储池未挂载的连锁反应存储池 A 和 B 未能成功挂载,导致虚拟机进程⽆法访问磁盘数据。

虚拟机在尝试 I/O 操作时陷⼊阻塞状态,导致 CPU 和内存资源耗尽。

2. 系统⾼负载与 SSH/KVM 失效CPU 使⽤率 99.5%:表明系统中的⽤户进程或内核进程出现资源竞争。

内存使⽤率 84%:可能由于阻塞进程堆积,内存压⼒上升,触发 OOM (内存不⾜)⾏为。

系统在⾼负载下暂停 SSH 和 BMC 进程,使管理员⽆法通过远程访问登录系统排查问题。

3. dmesg 中的 BAR 13 分配失败关键⽇志信息如下:这条⽇志表明 PCI 资源分配不⾜,可能影响某些存储设备(如 HBA 卡或 RAID 控制器)正常⼯作。

4. crontab 任务过多导致系统资源耗尽通过⽇志分析,发现有⼤量 ⾃动任务被频繁触发,导致系统在短时间内创建⼤量会话:在 CPU 和内存接近饱和的情况下,这些任务进⼀步恶化了系统性能。

三、核⼼原因分析PCI: BAR 13: No available resource for PCI bridgesession_start: 400 sessions activeNo. 1 / 4三、核⼼原因分析1. 存储池挂载失败的具体原因PCI BAR 分配失败直接导致某些 PCI 设备(如 RAID/HBA 卡)⽆法正常注册资源,进⽽导致存储设备不可⽤:PCI: BAR 13: No available resource for PCI bridgeBAR(Base Address Register)是 PCI 设备⽤于内存映射的地址寄存器,分配失败意味着系统未能为该设备提供必要的地址空间,导致存储池不可访问。

系统虚拟化技术性能评测

系统虚拟化技术性能评测

电信科学2010年第8A 期虚拟化已成为企业数据中心有效整合资源、降低成本的重要技术,并且是云计算平台的重要组成部分。

目前在工业界和学术界存在多种可供选择的虚拟化技术,本文首先对物理机和KVM 、硬件辅助虚拟化的Xen 、Xen 半虚拟化、VirtualBox 等开源虚拟化技术部署的虚拟机进行了性能基准测试,然后基于测试数据进行深入解读和分析。

最后,结合各种虚拟化技术的性能评测结果,针对处理器密集型应用、磁盘I/O 密集型应用和网络I/O 密集型应用等虚拟化应用场景,为企业和科研用户在不同的应用场景中选择具体的虚拟化技术提出了切实的建议。

关键词虚拟机;虚拟化;性能测试系统虚拟化技术性能评测*兰雨晴1,2,宋潇豫2,马立克2,徐舫2(1.北京航空航天大学计算机学院北京100191;2.上海中标软件有限公司创新中心北京100190)摘要1引言计算机平台的虚拟化技术已有40多年的历史,它起源于对分时操作系统的研究[1]。

最早使用虚拟化技术的IBM7044计算机能够在一台物理机上运行多个独立客户操作系统系统,目的是为了让用户尽可能地充分利用昂贵的大型机资源。

虚拟机技术是在软、硬件之间引入虚拟层,可为应用程序提供独立的运行环境,屏蔽硬件平台的动态性、分布性和异构性,支持硬件资源的共享和复用,并为每个用户提供属于个人的独立、隔离的计算环境,同时,为管理员提供硬件资源和软件资源的集中管理[2]。

随着x86处理器性能的提升和应用的普及,虚拟化技术在x86平台上得到了迅速的发展和广泛的应用。

虚拟化技术目前的主要用途是测试开发以及服务器资源整合。

虚拟化技术按照不同的实现方式可以分为全虚拟化(full virtualization )、半虚拟化(paravirtualization )和硬件辅助虚拟化(hardware assisted virtualization )。

全虚拟化和半虚拟化主要通过软件方式实现虚拟化,全虚拟化采用二进制代码动态翻译(dynamic binary translation )技术访问虚拟硬件,半虚拟化技术将敏感指令替换为对虚拟机监控器的超级调用(hypercall ),避免每条指令的翻译,但这两种方式都会带来一定程度的性能开销。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

*The National Natural Science Foundation of China under Grant No. 90718028, 60873052 (国家自然科学基金); the National Grand Basic Research 973 Program of China under Grant No. 2007CB310900 (国家重点基础研究发展规划(973)); the National High-Tech Research and Development of China under Grant No. 2008AA01Z112 (国家高技术研究发展计划(863)); the MOE-Intel Information Technology Foundation under Grant No. MOE-INTEL-10-06 (教育部-英特尔信息技术专项科研基金). Received 2010-09, Accepted 2010-11.ISSN 1673-9418 CODEN JKYTA8 E-mail: fcst@ Journal of Frontiers of Computer Science and Technology 1673-9418/2011/05(06)-0493-08 Tel: +86-10-51616056DOI: 10.3778/j.issn.1673-9418.2011.06.002虚拟机陷出的检测及分析*汪小林1, 张彬彬1, 靳辛欣1, 王振林2, 罗英伟1+, 李晓明11. 北京大学 信息科学技术学院, 北京 1008712. 密西根理工大学 计算机系, 美国 密西根州 49931-1295Detection and Analysis of Virtual Machine Exits *WANG Xiaolin 1, ZHANG Binbin 1, JIN Xinxin 1, WANG Zhenlin 2, LUO Yingwei 1+, LI Xiaoming 11. School of Electronics Engineering and Computer Science, Peking University, Beijing 100871, China2. Department of Computer Science, Michigan Technological University, Michigan 49931-1295, USA + Corresponding author: E-mail: lyw@WANG Xiaolin, ZHANG Binbin, JIN Xinxin, et al. Detection and analysis of virtual machine exits. Journal of Frontiers of Computer Science and Technology, 2011, 5(6): 493-500.Abstract: It’s essential to learn about sensitive instructions that cause virtual machine (VM) to exit to the virtual machine monitor (VMM) to find new ways to optimize the performance of VM. This paper proposes a novel method, competition in bucket method (CBM), to track all VM exits efficiently, by mapping sensitive instructions to buckets according to instruction addresses, and find out hot instructions in each bucket.Key words: virtualization; virtual machine monitor (VMM); hot instructions; virtual machine exits; competition in bucket method (CBM)摘 要:虚拟机执行敏感指令时会陷出到虚拟机管理器(virtual machine monitor, VMM)处理, 虚拟机频繁陷出是影响虚拟化性能的重要因素, 因此全面了解导致陷出的敏感指令对虚拟化性能优化有重要意义。

提出了一个创新性的方法“桶竞争法”(competition in bucket method, CBM), 通过把敏感指令的地址映射到不同494 Journal of Frontiers of Computer Science and Technology计算机科学与探索 2011,5(6)的桶中, 采用竞争方式在各个桶内寻找陷出次数最多的几个地址, 能高效地跟踪所有的虚拟机陷出。

关键词:虚拟化; 虚拟机管理器(VMM); 热指令; 虚拟机陷出; 桶竞争法(CBM)文献标识码:A 中图分类号:TP3111引言Intel和AMD都分别提供了硬件辅助虚拟化技术——VT(virtualization technology)和SVM(security virtual machine), 可以支持X86结构的全虚拟化[1−4]。

Intel的VT为虚拟化提供了两种虚拟机执行(virtual machine execution,VMX)模式:VMX root模式和VMX non-root模式。

虚拟机管理器(virtual machine monitor,VMM)运行在root模式, 而客户操作系统(guest operating system, guest OS)运行在non-root模式。

系统控制权从VMM进入到guest OS叫作“虚拟机陷入”; 反之, 从guest OS进入到VMM叫作“虚拟机陷出”。

大多数虚拟机的陷出是由于guest OS执行敏感指令所引起的。

当VMM完成模拟指令操作之后, 系统将切换回non-root模式, 控制权也转交给guest OS。

利用硬件的扩展来辅助实现VMM的功能, 无需改动guest OS或依赖于二进制翻译。

但是迄今为止, 无论是VT还是SVM都没有对内存管理单元(memory management unit, MMU)和I/O设备提供有效的支持。

使用VT或SVM技术的VMM的性能仍然不尽人意,经常落后于使用二进制翻译的VMM[5]。

造成这种现象的一个主要原因是大量的虚拟机陷出带来了很多额外的系统开销。

在VT-x的全虚拟化环境下, 分别在KVM-54[6]和Xen-3.2.1[7]上运行一组典型的基准测试程序, 并统计虚拟机陷出的总次数以及由于I/O和缺页中断所引起的陷出次数, 结果如表1所示。

可以看到, 由I/O陷出和缺页中断引起的虚拟机陷出占了相当大的比例(超过56%), 因此如果能够减少这两种类型的虚拟机陷出, 就能够大大减少全虚拟化的系统开销。

表1说明了不同类型的应用程序产生不同的虚拟机陷出模式。

本文提出了一种高效的方法用于在线跟踪虚拟机陷出, 能够捕获到大部分最热的陷出, 然后进一步对它们进行相应的优化[8], 这种捕获陷出的方法称为桶竞争法(competition in bucket method, CBM)。

对于每个虚拟机陷出, 可以用O(1)的时间对它进行计数。

在程序运行的任意时刻, 用O(K)的时间就可以得到K个最热的虚拟机陷出。

本文对CBM进行了具体的论述:第2章介绍了如何用桶竞争法跟踪虚拟机陷出; 第3章分析了CBM的两个主要特点; 第4章对CBM的效果进行了测试和分析; 第5章为总结。

2 利用CBM跟踪虚拟机陷出一般说来, 存在着两种虚拟机陷出:外部中断(包括非屏蔽中断)引起的虚拟机陷出和敏感指令(如特权指令和引起异常的指令)引起的虚拟机陷出。

人们所关注的是敏感指令引起的陷出。

能通过Table 1 Count and reason of VM exits表1虚拟机陷出的个数和原因KVM Xen Page fault I/O Page fault I/OProgramCount VM exits/(%)CountVM exits/(%)TotalCountVM exits/(%)CountVM exits/(%)TotalKernel Compile 7.4E6 83.36 7.6E5 8.59 8.9E6 1.1E781.23 1.2E6 9.03 1.3E7 SpecJBB 3.5E5 2.996.5E6 59.571.1E7 3.5E5 4.22 5.0E6 59.89 8.3E6SpecCPU 3.4E7 18.691.0E8 55.981.8E8 1.1E850.41 5.6E7 24.902.2E8SpecWeb 5.6E6 15.501.4E7 40.793.6E7 1.1E731.46 1.2E7 33.04 3.7E7汪小林等:虚拟机陷出的检测及分析495指令在guest OS的访存地址标识这一类指令。

当一条敏感指令引起虚拟机陷出时, 处理器从guest OS 的non-root模式退出, 切换到VMM的root模式, 同时将虚拟机此刻的状态, 包括引起陷出的指令地址保存在它的虚拟机控制结构(virtual machine control structure, VMCS)中。

根据程序的局部性原理, 可以假设, 大多数的虚拟机陷出是由分布在特定地址范围内的一小部分敏感指令所引起的。

不妨称这种性质为“虚拟机陷出局部性”。

对于给定的K(如K=16), 称这K个发生最频繁的虚拟机陷出为“热陷出”。

利用CBM 可以高效地探测到所有热陷出。

在CBM中, 引入结构struct hot_exit来保存每个有可能成为“热陷出”的虚拟机陷出。

结构中记录了指令的地址(成员rip)和出现次数(成员exit_ count)。

为了得到K个热陷出, 将MAX_BUCKETS 设为2K, 即设置2K个桶。

每个桶用结构struct hot_ bucket表示, 用来存储MAX_HOT+1个struct hot_exit 记录。

结构struct hot_exit和结构struct hot_bucket 的定义如以下代码所示:1. struct hot_exit {2. u32 rip;3. u32 exit_count;4. };5. struct hot_bucket {6. struct hot_exit hot_exits[MAX_HOT+1];7. u32 total_exits;8. u32 padding[HOT_P ADDING];9. };10. struct hot_bucket hot_buckets[MAX_BUCKETS];跟踪热陷出的算法的代码如下:11. void hot_touch(struct hot_bucket * hot_buckets,u32 rip) {12. int i, index = hash_index(rip);13. struct hot_exit * hot_exits =hot_buckets[index].hot_exits;14. hot_buckets[index].total_exits++;15. if (hot_buckets[index].total_exits == 0) {16. hot_buckets[index].total_exits =(hot_buckets[index].total_exits−1)/2;17. for (i = 0; i<=MAX_HOT; i++) {18. hot_exits[i].exit_count /=2;19. }20. }21. for (i = 0; i<=MAX_HOT; i++) {22. if (hot_exits[i].rip == rip) {23. hot_exits[i].exit_count++;24. if (i > 0 &&hot_exits[i].exit_count>hot_exits[i−1].exit_count){25. struct hot_exit temp = hot_exits[i];26. hot_exits[i] = hot_exits[i−1];27. hot_exits[i−1] = temp;28. }29. return;30. }31. }32. hot_exits[MAX_HOT].rip = rip;33. }当虚拟机陷出发生时, 调用hot_touch去跟踪这个陷出。

相关文档
最新文档