NIST 特别出版 800-125A 修订版本 1

基于服务器的虚拟机监视器平台的安全性建议

Ramaswamy Chandramouli 著

计算机安全分部，信息科技实验室

此出版物可从此处免费获得：

https://doi.org/10.6028/NIST.SP.800-125Ar1

2018 年六月

美国商务部 秘书 Wilbur L. Ross, Jr.

美国国家标准技术研究所 NIST 主任和标准技术商务次长 Walter Copan

权力范围

此出版物由 NIST 开发以符合其在 2014 年的美国联邦信息安全现代化法案（FISMA），美国法典第 44 章 3551 节及其下的内容，公法（P.L.）113-283。NIST 负责为联邦信息系统开发信息安全标准和指南，但是这些标准和指南不应该被应用于国家安全系统，如果没有对这些系统行使政策权力的适当的联邦官员的明确许可。此指南同美国行政管理和预算局（OMB）公告 A-130 的要求相一致。

此出版物中的任何内容都不应该被用于否认由美国商务部秘书在法定权力下规定的对于联邦政府机构具有强制性和法律约束力的标准和指导意见。这些指导意见也不应该被解读为更改或者取代商务部秘书、行政管理和预算局主任，或是任何其他联邦官员的现有权力。此出版物可以在自愿的基础上被非政府组织使用，并且不受美国版权的限制。但是 NIST 要求署名权。

美国国家标准技术研究所特别出版 800-125A 修订版本 1

Natl. Inst. Stand. Technol. Spec. Publ. 800-125A Rev. 1，38 页（2018 年六月）

https://doi.org/10.6028/NIST.SP.800-125Ar1

CODEN：NSPUE2

此文档中可能会提到某些商业实体、设备或者器材以便充分地描述某种试验程序或者概念。这样的提名的本意并非暗示 NIST 对其的推荐或认可，也非暗示这些实体、器材或者设备一定是可用于该目的之最好的。

此文档中可能会有对于 NIST 的当前正在开发中的其他出版物的引用，以便符合其被赋予的法定责任。此出版物中的信息，包括概念和方法论，可以被联邦政府机构使用，即使是在这些附带的出版物完成之前。因此，直到每部出版物完成之前，当前的要求、指导意见和过程在其所存在之处仍然有效。关于计划和迁移的目的，联邦政府机构可能想要紧密跟踪由 NIST 提供的这些新出版物的进展。

我们鼓励组织机构在公开评论期间审阅所有出版物草案，并且向 NIST 提供反馈。除了上述出版物以外，NIST 的众多计算机安全出版物可以从 https://csrc.nist.gov/publications 获取。

关于此出版物的评论可以被提交至：

美国国家标准技术研究所

收件人：计算机安全分部，信息科技实验室，办事处大道 100 号（8930 邮递点），盖瑟斯堡，马里兰州 20899-8930

邮件：sp800-125A-comments@nist.gov

所有评论必须在美国信息自由法（FOIA）条款下发布。

计算机系统技术报告

位于美国国家标准技术研究所（NIST）的信息科技实验室（ITL）通过为国家的测定和标准基础设施提供技术领导来提升美国经济和公众福利。ITL 通过开发测试、测试方法、参考数据、概念实现的证明以及技术分析来推进信息科技的发展及其生产性的使用。ITL 的职责包括为联邦信息系统中的国家安全相关信息以外的成本高效的安全性和隐私性开发管理、行政、技术和物理方面的标准和指导意见。此特别出版 800 系列报导了 ITL 的研究、指导意见及其在信息系统安全领域的延伸努力，以及与行业、政府和学术组织之间的合作活动。

摘要

虚拟机监视器平台是一系列提供了硬件资源（诸如 CPU、内存、网络和存储等）虚拟化的软件模块的集合，并且因此允许称为虚拟机（VM）的多个计算栈（由操作系统（OS）和应用程序构成）运行在单一物理宿主上。此外，它还可能拥有在单一物理宿主内部定义网络（称为虚拟网络）的功能，以允许驻留在该宿主上的虚拟机之间以及该宿主外部的物理和虚拟机之间的通讯。由于有了全部这些功能，虚拟机监视器负有责任以调度对于物理资源的访问、在驻留的虚拟机之间提供运行时隔离，以及启用虚拟网络，该虚拟网络在虚拟机之间以及虚拟机和外部网络之间提供保持安全性的通讯流。虚拟机监视器的架构可以以不同方式进行分类。此文档中的安全性建议是关于保证虚拟机监视器的基线功能的安全执行的，并且因此对于虚拟机监视器的架构不可知。更进一步地，这些建议适用于针对服务器虚拟化而部署的虚拟机监视器的上下文环境，因此并不适用于其他应用案例，诸如嵌入式系统和桌面。关于虚拟网络的安全配置的建议在另一篇 NIST 文档中解决（特别出版 800-125B）。

关键字

虚拟化；虚拟机监视器；虚拟机；虚拟网络；安全配置；安全性监视；客户操作系统

致谢

作者 Ramaswamy Chandramouli 想要感谢他的同事 Tim Grance，由于他个人对内容的贡献以及对于此出版物的组织工作的帮助。特别感谢来自 Bosch Center of Competence Security 的 Andreas Bartelt，由于他对于关于设备虚拟化技术的宝贵贡献。作者还想感谢 Michael Bartock，由于他作为分部读者的宝贵审阅和反馈。最后，同样重要的是，作者感谢 Isabel van Wyk，由于她的详细的编辑审阅。

对审稿人的注记

此修订版本包括用于设备虚拟化的额外技术，诸如准虚拟化、透传和自虚拟化的硬件设备等，以及相关的安全性建议。此修订版本中的主要内容更改位于第 1.1、2.2.2 节和第 5 章。

执行摘要

服务器虚拟化现在是用于数据中心和云服务中的企业级信息科技（IT）基础设施的一种已经确立的技术，由于它能够提供对于硬件资源的更佳利用，减少所需的物理空间，并且减少能耗和管理开销。用于服务器虚拟化的核心软件称为虚拟机监视器，它直接提供中央处理器（CPU）和内存的虚拟化。同它的支持模块一起，它允许所有硬件资源（例如 CPU、内存、网络和存储等）的虚拟化，并且因此允许多个称为虚拟机（VM）或者客户机的计算栈，其中每一个都托管操作系统（OS）（客户机 OS）和应用程序，运行在单一的物理宿主上。此物理宿主称为虚拟化宿主或者虚拟机监视器宿主。由于虚拟机监视器就其自身而言不能提供服务器虚拟化所需的所有功能，它拥有用于设备（例如网络和存储设备）虚拟化的软件模块（例如设备驱动程序），以及用于虚拟机生命周期操作和虚拟机监视器配置的管理模块。虚拟机监视器与这些支持模块以及宿主硬件一起构成了虚拟机监视器平台。虚拟机监视器可以直接安装在硬件或者裸机上（第 1 类虚拟机监视器），也可以安装在称为宿主操作系统的完整的传统操作系统上（第 2 类虚拟机监视器）。

初看起来，与虚拟机监视器及其硬件宿主（共同称为虚拟机监视器平台）的安全管理相关的所有活动可能看起来应该只是包含任何服务器级别的软件及其托管环境的已确立的最先进的技术实践。然而，仔细检查一下就会发现，用于支持虚拟机监视器所提供的硬件虚拟化的功能具有广泛的安全性后果，并且因此需要一组基于针对这些功能的安全执行的威胁的分析的目标明确的安全性建议。

由于存在多种方式对虚拟机监视器架构进行分类，此文档中所采用的方式是识别虚拟机监视器所执行的基线功能、每一项基线功能所涉及的任务、该任务的安全执行的潜在威胁，以及以安全性建议的形式给出的，能够提供担保以对抗利用这些威胁的反制措施。

以下 5 种功能被识别为虚拟机监视器平台的基线功能：

• VM 进程隔离
• 设备调度和访问控制
• 来自客户 VM 的命令的直接执行
• VM 生命周期管理
• 虚拟机监视器平台的管理

除了为保证上述基线功能的安全执行提供安全性建议以外，此文档还提供了关于保证虚拟机监视器平台的所有组件的整体完整性的建议。这些建议涵盖了第 1 类和第 2 类虚拟机监视器。

此文档并未涵盖用于虚拟机监视器所安装在其上的物理宿主的程式化管理功能的安全执行。用于反制物理访问威胁以及用于运行在 VM 上的客户 OS 和应用程序的保护要求及其相关联的安全性建议同样超出了此文档的范围。更进一步地，这些安全性建议适用于针对服务器虚拟化而部署的虚拟机监视器，并且并不涵盖其他应用案例，诸如面向桌面和嵌入式系统的虚拟机监视器应用。

第 1 章 简介、范围和目标受众

虚拟机监视器是提供服务器虚拟化的核心软件。同它的支持模块一起，它允许所有硬件资源（例如 CPU、内存、网络和磁盘等）的虚拟化，并且因此允许多个计算栈（基本上是由 OS 和应用程序构成）运行在单一的物理宿主上。这样的物理宿主称为虚拟化宿主（在此文档中有时也称为虚拟机监视器宿主），独立的计算栈被封装在称为虚拟机（VM）的东西中。为了成为独立可执行的实体，VM 的定义应该包括分配给它的资源（例如 CPU、内存等）。VM 也称为“客户机”，而它们内部运行的操作系统（OS）称为“客户 OS”。与 VM 相关联的资源是虚拟资源，与同物理宿主相关联的物理资源相对。虚拟机监视器同这些支持模块以及托管硬件一同构成了虚拟机监视器平台。

虚拟机监视器的主要功能是强制执行客户 OS 隔离，以及客户 VM 之间的受控资源共享。因此它起到了传统 OS 对于非虚拟化的宿主（服务器）所起的作用中的很多。正如传统 OS 为运行在服务器上的不同应用程序（或者进程）之间提供隔离那样，虚拟机监视器为运行在其上的一台或者多台 VM 之间提供隔离。同样，类似于 OS，虚拟机监视器在多个 VM 之间调度其对物理资源（设备）的访问。尽管对于 CPU 和内存访问（以保证进程隔离）直接由虚拟机监视器处理（分别通过指令集（CPU）虚拟化和内存虚拟化，不论是否得到来自硬件的辅助），虚拟机监视器通过调用运行于内核之中的，或者称为设备驱动程序 VM 的专用 VM 之中的软件模块来处理对设备访问（设备虚拟化）的调度。虚拟机监视器可以直接安装在硬件或者裸机上（第 1 类虚拟机监视器），或者安装在称为宿主 OS 的完整传统 OS 上（第 2 类虚拟机监视器）。

初看起来，与虚拟机监视器及其硬件宿主（共同称为虚拟机监视器平台）的安全管理相关的所有活动可能看起来应该只是包含任何服务器级别的软件及其托管环境的已确立的最先进的技术实践。然而，仔细检查一下就会发现，用于支持虚拟机监视器所提供的硬件虚拟化的功能具有广泛的安全性后果，并且因此需要一组基于针对这些功能的完整性的威胁的分析的目标明确的安全性建议。在此文档中，这些功能称为虚拟机监视器的基线功能。

虚拟机监视器的基线功能包括：

• VM 进程隔离
• 设备调度和访问控制
• 来自客户 VM 的命令的直接执行
• VM 生命周期管理
• 虚拟机监视器平台的管理

对于上述功能的简略描述于下文 1.1 节给出。

1.1 虚拟机监视器的基线功能（HY-BF）

尽管虚拟机监视器的基本功能是虚拟化硬件（物理宿主）以允许运行多个虚拟宿主（普遍称之为 VM），商业虚拟机监视器供应带有不同的特性集合。提供相同特性集合的模块在不同的产品供应中被起了不同的名称。因此，为了达到此文档的目的，有必要定义一组虚拟机监视器的基线特性，它们能够涵盖用于支持硬件虚拟化的全部功能。在某些实例中，只是为 VM 提供一组虚拟化资源的模块称为虚拟机管理器（VMM）。如果 VMM 同提供 OS 层级服务的模块，诸如 CPU 中的 VM 计划相结合，它们便称为虚拟机监视器。虚拟机监视器的这些特性或者功能包括：

• HY-BF1：VM 进程隔离——提供 VM 执行计划，管理在 VM 中运行的应用程序进程，诸如 CPU 和内存管理，以及在 VM 中运行应用程序的过程中进行不同的处理器状态之间的上下文切换。为了保证 VM 进程隔离，来自支持直接内存访问（DMA）设备的内存访问需要受到虚拟机监视器的控制（例如通过输入输出内存管理单元（IOMMU））。然而，此功能被认为属于 HY-BF2，由于它属于设备调度。
• HY-BF2：设备调度和访问控制——使设备对于 VM 可用（例如通过模拟、准虚拟化、透传或者自虚拟化的硬件设备），并且控制哪些 VM 被允许访问哪些设备（例如网卡（NIC），诸如 IDE 驱动器的存储设备等）。
• HY-BF3：来自客户 VM 的命令的直接执行——某些来自客户 OS 的命令是由虚拟机监视器直接执行的，而非通过中断或者上下文切换而触发。此功能适用于那些实现了准虚拟化而非完全虚拟化的虚拟机监视器。
• HY-BF4：VM 生命周期管理——包括 VM 镜像的创建和管理、VM 状态的控制（开始、暂停、停止）、VM 迁移、制作快照、VM 监视，以及策略的强制执行等全部功能。
• HY-BF5：虚拟机监视器平台的管理——定义虚拟机监视器软件模块中的不同配置参数中的东西和设置值，包括适用于虚拟机监视器中的虚拟网络以及这些模块的更新和补丁的配置的东西和设置值。

关于这 5 种基线功能的简略描述足以指导此文档剩余部分的讨论。关于这些功能的详细讨论于附录 A 提供。

上述功能由不同的虚拟机监视器组件或者软件模块执行。在不同的虚拟机监视器产品之间，功能的分布方式存在一些次要差别。虚拟机监视器组件的这些功能以及这些组件的位置在总体的虚拟机监视器架构中的映射于下文的表格 1 中给出：

表 1：虚拟机监视器平台的基线功能

一般来说，功能 HY-BF1 和 HY-BF3 由运行于内核中的共同称为“虚拟机监视器”的模块提供，而 HY-BF2 由运行于专用 VM（称为设备驱动程序 VM）或者虚拟机监视器内核自身之中软件模块启用。功能 HY-BF4 和 HY-BF5 由称为管理或者服务控制台的模块，或者通过内核模块执行。正如执行 HY-BF2 功能的模块那样，此控制台是一个软件层，它通常不是构建于虚拟机监视器内核之中，而是作为一个高权限 VM 运行于其上，并且可以由安装于其中的完整 OS 或者由用于为应用程序接口（API）（shell 和网络访问）提供实用程序功能的超轻量级 OS 构建，这些功能只是用于辅助执行虚拟机监视器特定的配置和管理任务。

1.2 此文档的范围

为服务器虚拟化而部署的虚拟机监视器的架构可以按照不同方式分类：

• (a) 基于虚拟机监视器所安装于其上的实体——第 1 类虚拟机监视器和第 2 类虚拟机监视器（已描述）
• (b) 基于虚拟化的类型
  • 完全虚拟化——虚拟机监视器将真实世界中存在的硬件设备的接口暴露出来，并且该设备的驱动程序对于客户 OS 可用，并且虚拟机监视器将会完全模拟该设备的行为。这种模拟允许 VM 中运行的程序使用 VM OS 的驱动程序，此驱动程序被设计为同被模拟的设备进行交互，而无需安装任何由虚拟机监视器厂商指定的特定驱动程序或工具。
  • 准虚拟化——虚拟机监视器将并不存在于真实世界中的设备暴露出来，它只是软件，并且带有轻量级的接口。然而，此种场景要求 VM 中具有特定的驱动程序，有时要求对客户 OS 进行修改。这种方式的本意是提升 VM 中运行的应用程序的性能水平，相对于完全虚拟化所采用的模拟方式而言。

此文档中所描述的虚拟机监视器平台所假设的信任模型如下所述：

• VM 中的所有组件均为不可信，包括客户 OS 及其运行于内核空间的相关实用工具（例如客户设备驱动程序）以及运行于用户空间的所有应用程序
• 虚拟机监视器平台内部实现的设备驱动程序不可信，除非它们带有安全证书
• 用于在 VM 之间提供隔离的虚拟机监视器内核组件可信
• 宿主 OS 对于第 2 类虚拟机监视器可信
• 虚拟机监视器宿主的硬件可信

有了关于虚拟机监视器架构的背景信息，以及假设的信任模型以后，对于 5 种基线功能（HY-BF1～HY-BF5）的安全性建议的范围涵盖下列方面：

• 与功能 HY-BF1、HY-BF2 和 HY-BF4 相关联的所有任务
• HY-BF3 与准虚拟化的虚拟机监视器的超级调用的处理相关联，它是虚拟机监视器的可信功能，并且并未包含于安全性建议中
• HY-BF5 之下的所有任务都被包括进来，除了与虚拟网络的定义和配置相关联的内容（虚拟网络的安全配置由另一篇 NIST 文档 SP800-125B 所涵盖）

同时提供了用于保证整体平台完整性的建议。

安全性建议并未涵盖下列内容：

• 虚拟机监视器宿主的用户帐户管理
• 虚拟机监视器宿主的认证和访问控制
• 宿主 OS 的程式化管理（例如保持补丁为最新）
• 客户 OS 的程式化管理
• 运行于 VM 上的客户 OS 的安全性
• 运行于 VM 上的应用程序/服务的安全性

1.3 目标受众

此文档中的安全性建议的目标受众如下：

• 想要开发虚拟化基础设施以便在虚拟机（VM）上托管不同的业务（LOB）应用程序系统的私人企业或者政府机构的企业 IT 部门的首席安全官（CSO）或者首席技术官（CTO）
• 想要提供虚拟化基础设施以便为云服务客户托管安全的云服务，诸如基础设施即服务（IaaS）的数据中心管理者

1.4 与其他 NIST 指南文档的关系

就技术领域而言，与此文档相关联的 NIST 指南文档是 NIST 特别出版（SP）800-125，完全虚拟化技术安全性指南。与当时的技术发展状态相一致（SP800-125 发布于 2011 年一月），SP800-125 为两种虚拟化应用范型：服务器虚拟化和桌面虚拟化中的组件应用提供了高级安全性建议。此后，服务器虚拟化在 IT 数据中心领域得到了广泛应用，既用于托管机构内部或者预先定制（企业）的应用程序，也用于为云服务托管应用程序以及提供计算单元。

伴随这一技术应用趋势而来的是虚拟机监视器的特性集合，以及用于配置和管理由虚拟机监视器衍生出来的虚拟化的基础设施的工具集合的市场可获得性的增加。此文档的目标是专注于一组用于虚拟机监视器（及其所有构成组件）的部署，包括 VM 的创建和供货所涉及的步骤的安全性建议的开发。此文档在类似的 NIST 指南文档的上下文环境中所提供的这组安全性建议的独特特性列于下方：

• 提供了一组目标明确的安全性建议，它们对于虚拟机监视器的部署是架构不可知的
• 由于真实世界中的部署过程包括 VM 供货，因此所有 VM 生命周期操作都被涵盖，从 VM 镜像的创建和管理到它们的使用粒度权限的管理
• 由于认识到虚拟机监视器是一种基于目的构建的操作系统（OS）内核，以及服务器 OS 的安全性取决于它的最弱一环这两点，无论其发行版（例如驱动程序软件），此文档也提供了与这些组件相关联的安全性建议
• 由于认识到虚拟机监视器会执行特定的高权限操作，而不会受到来自虚拟化的宿主中的任何其他实体的干涉，以及为这些操作撬动硬件支持将会为虚拟机监视器的部署的整体安全性带来显著差异这两点，这些安全性建议也会提升性能，如果虚拟化特定的功能（例如多个 VM 的内存表）被卸载（撬动）到处理器而非通过软件功能实现
• 所有安全性建议的本意是提供担保以对抗那些针对虚拟机监视器的基线功能所涉及的任务的威胁的利用

第 2 章 开发安全性建议的方式

开发针对诸如虚拟机监视器的复杂软件的部署和使用的安全性建议需要对于潜在威胁的了解，这些威胁一旦被利用，将会影响虚拟机监视器功能的机密性、完整性和可用性这 3 种安全属性。此文档中用于开发针对虚拟机监视器的部署的安全性建议的方式如下所述：

• 保证虚拟机监视器平台的所有组件的完整性，从宿主的基本输入/输出系统（BIOS）到虚拟机监视器的所有软件模块。这可以通过第 3 章作为 HY-SR1 而列出的安全启动过程来实现
• 识别典型虚拟机监视器平台中的威胁来源。简要讨论了来自恶意或者受到攻击的 VM 的威胁的本质（2.1 节）
• 对于 5 种基线功能 HY-BF1～HY-BF5 中的每一种（除了 HY-BF3，由虚拟机监视器执行高权限操作以外），识别每一种功能之下的不同任务，并且对于每一种任务，识别对于该任务的安全执行的潜在威胁。那些能够提供担保以对抗这些威胁的利用的反制措施构成了安全性建议的基础（2.2 节）

必须注意到的是，在某些大型开源和商业软件环境的案例中（例如数据库管理系统（DBMS）平台），用于安全部署和使用的方式是研究发布于公开漏洞数据库中的关于不同产品供应的报告，通过在线公开论坛或者软件厂商查找可用的补丁，并且查找建议的安全配置设置（同样通过在线公开论坛或者软件厂商的网站）。我们并未在此文档中采用此方式，由于此文档本意中的目的并非为某个特定的开源或者商业虚拟机监视器产品供应提供安全性建议，而是为整个产品类型基于其基线功能提供安全性建议。

2.1 虚拟机监视器平台的威胁来源

虚拟机监视器软件驻留在连接到企业网络的物理宿主上，它拥有被远程管理的能力。与此同时，它支持多个通常是该物理宿主内部的软件定义的虚拟网络结点的虚拟宿主（虚拟机或者 VM）。在某些情况下，它们可以是隔离网络的结点或者共享宿主网络。基于这一场景，某人可以识别针对虚拟机监视器平台的 3 种基本威胁来源，每一种均由符号 HY-TS# 标识：

• HY-TS1：来自或者通过虚拟机监视器（虚拟化的宿主）所驻留于其中的企业网络的威胁
• HY-TS2：通过诸如共享虚拟机监视器内存以及虚拟机监视器宿主内部的虚拟网络等信道，产生自恶意或者受到攻击的 VM 的威胁
• HY-TS3：来自网络接口，面向 VM 管理守护进程和虚拟机监视器管理控制台的威胁

来自来源 HY-TS1 和 HY-TS3 的威胁普遍存在于所有服务器级别的软件，并且在其他 NIST 文档中被良好地认识和应对。而来自来源 HY-TS2 的威胁是由虚拟机监视器所定义的虚拟化环境所特有的。我们将会在下一节中审视来自 HY-TS2 的威胁的本质。

虚拟机监视器控制着 VM 对物理硬件资源的访问，并且在 VM 之间提供隔离。VM 对诸如 CPU 和内存的硬件资源的访问由虚拟机监视器直接控制，而对于诸如网络和存储设备等资源的访问则是通过驻留于内核模块或者高权限 VM（即管理 VM）中的模块（驱动程序）来控制的。VM 之间的网络隔离是通过为每个 VM 指认一个独特的网际协议（IP）或者介质访问控制（MAC）地址、定义虚拟局域网（VLAN）或者覆盖网络并且为每个 VM 指认适当的网络标识符的方式来提供。来自恶意或者受到攻击的 VM 的威胁的本质可以通过以下方式来表明：

注意，每一种威胁由符号 HYP-T# 来进行标识，其中 HYP 表示虚拟机监视器，T 表示威胁，# 表示序号。

• 进程隔离突破——VM 逃逸（HYP-T1）：来自恶意 VM 的针对任何虚拟机监视器的主要威胁。恶意 VM 成功地破坏了由 VMM/虚拟机监视器提供的对于诸如内存页和存储设备等硬件资源的隔离功能。换言之，恶意或者受到攻击的 VM 可以访问属于虚拟机监视器或者其他 VM 的内存区域，以及它们未被授权访问的存储设备。此类威胁的可能原因包括：(a) 虚拟机监视器的设计漏洞，或者 (b) 恶意或者易受攻击的设备驱动程序。由恶意 VM 获得虚拟机监视器的控制权带来的潜在下游影响包括安装 rootkit 或者对于同一虚拟化的宿主上的其他 VM 的攻击
• 网络隔离突破（HYP-T2）：针对隔离的潜在威胁包括诸如由恶意 VM 进行的 IP 或者 MAC 地址伪造以及流量窥探，或者旨在针对同一虚拟网段上的 VM 的虚拟网络流量的拦截等攻击。对这些网络控制的破坏所造成的影响是机密性的丧失。某些 VM 将会能够查看它们并未被授权查看的信息
• 拒绝服务（HYP-T3）：配置不当的或者恶意 VM 可能会消耗不成比例的高百分比的宿主资源，导致对于该虚拟机监视器宿主上的其他 VM 的拒绝服务

2.2 针对虚拟机监视器的基线功能的潜在威胁

本节检查了虚拟机监视器的 5 种基线功能（除了 HY-BF3 以外）中的每一种的每一项任务，并且对于针对这些任务的安全执行的威胁通过与上一节中标识出的原因进行关联以加以分析。

2.2.1 针对 HY-BF1 的潜在威胁

针对虚拟机监视器的 HY-BF1 功能（VM 进程隔离）的主要威胁是进程隔离突破（HYP-T1）。如 2.1 节所述，造成此威胁的原因之一是虚拟机监视器的设计漏洞。适用于此威胁的某些潜在设计漏洞在这里加以讨论，并且带有对于它们所可能表现出来的上下文环境的解释。每一种漏洞以符号 HYP-DV# 标识，其中 HYP 表示虚拟机监视器，DV 表示设计漏洞，# 表示编号。

• 虚拟机控制结构（HYP-DV1）：为了适当地计划某个独立 VM 的任务（即由于每个客户 VM 被分配给一组虚拟 CPU（vCPU），它们称为 vCPU 任务），寄存器状态必须被适当地处理。为了允许保存和加载每个 vCPU 的状态，虚拟机监视器使用一种称为虚拟机控制结构（VMCS）的数据结构。对此数据结构的错误实现已知能够导致虚拟机监视器内存泄漏
• 处理敏感指令（HYP-DV2）：在不提供虚拟化辅助的硬件平台上，应该有一种软件机制以发现敏感或者关键指令，将其发送至 VMM（虚拟机监视器），并且在硬件执行它们之前，利用诸如二进制翻译等技术将其替换为较为安全的指令。未能捕获关键指令或者错误翻译中发生的任何错误都可能拥有其形式为客户 OS 被允许执行高权限指令的安全性启示
• 内存管理单元——MMU（HYP-DV3）：虚拟机监视器运行一种基于软件的内存管理单元（MMU），它为每个 VM 分配影子页表，由于客户 VM 不能被赋予对于基于硬件的 MMU 的直接访问权限，由于这可能会潜在地允许它们访问属于虚拟机监视器和其他共同托管的 VM （在某些情况下）的内存。然而，基于软件的 MMU 的错误实现可能导致任意地址空间的数据泄漏，诸如属于虚拟机监视器和共同托管的 VM 的内存段，因此导致内存隔离突破
• 输入/输出内存管理单元，IOMMU（HY-DV4）：虚拟机监视器撬动硬件输入/输出内存管理单元以对使用直接内存访问（DMA）的设备驱动程序和进程强制实施内存隔离。此特性构建于虚拟机监视器之中，并且利用固件开关在硬件中启用。如果未被启用，它可能导致一种漏洞，在此，DMA 可以潜在地被某一 VM 用作普通攻击向量，以覆盖由其他 VM 和进程使用的物理内存

其中，漏洞 HYP-DV1 和 DYP-DV2 应该通过适当地编写代码和测试这些模块来解决。因此，没有安全性保护措施可以被应用于部署和使用阶段。然而，内存侵犯漏洞 HYP-DV3 和 DMA 侵犯漏洞 HY-DV4 可以通过在这样的硬件平台上托管虚拟机监视器来解决，此硬件平台分别通过对于虚拟化警觉的硬件内存管理单元和通过 DMA 传输重映射进行 DMA 传输来提供内存虚拟化辅助。由于这 2 种漏洞，威胁 HYP-T1，进程隔离突破，将会在第 4 章通过安全性建议 HY-SR-2 得到解决。

进一步地，正确执行隔离要求每一个 VM 获取其所托管的应用程序所必需的适当的内存和 CPU 资源，并且不会发生拒绝服务。通过适当的内存分配选项配置来保证足够的内存这一点将会通过安全性建议 HY-SR-3 得到解决。而通过 vCPU 分配选项的适当配置来保证适当的虚拟 CPU 分配这一点将会通过安全性建议 HY-SR-4 和 HY-SR-5 得到解决。

2.2.2 针对 HY-BF2 的潜在威胁

在 VM 中执行的应用程序需要访问诸如网络和存储设备。对设备访问的调度在虚拟机监视器宿主中通过设备虚拟化（也称为 IO 虚拟化）来处理。有 3 种常见的设备虚拟化方式：(a) 模拟，(b) 准虚拟化，和 (c) 透传或者自虚拟化的硬件设备。

在模拟中，代码被如此实现以呈现某个虚拟设备，它拥有与之对应的真实（硬件）设备，客户 OS 已经拥有它的驱动程序。这允许运行未经修改的客户（VM），由此实现完全虚拟化。模拟代码运行于虚拟机监视器中。来自客户 VM 应用程序（通过其客户 OS）的 I/O 调用被虚拟机监视器内核拦截，并且转发到此代码，由于客户 VM 在此设置之下不能直接访问物理设备。这也可以将来自客户 VM 的模拟虚拟设备的访问多路传输至底层物理设备。

在准虚拟化方式中，虚拟机监视器向客户呈现某个人工设备的某个接口，此设备没有相应的硬件对应体。这允许在客户上安装特定的，简化的，对虚拟机监视器警觉的 I/O 驱动程序（称为准虚拟化的驱动程序）。来自客户 VM 中的这些准虚拟化的设备驱动程序的调用由另一个设备驱动程序（称为后端驱动程序）来处理，这些驱动程序直接与物理设备交互，并且调度来自准虚拟化的客户到该物理设备的访问。在某些实例中，来自准虚拟化的客户驱动程序的调用直接由虚拟机监视器通过其超级调用接口（与之相对应的调用称为超级调用）来处理。对于由这些超级调用产生的威胁的分析将于下一节提供。

设备虚拟化的第 3 种方式，透传方式（或者直接设备指认）被部署于这样的情形，在此，由于性能的原因，某个 VM 需要对于某个设备（例如 NIC、硬盘控制器、主机总线适配器（HBA）、USB 控制器、串口、火线控制器、声卡等）的专属访问，以避免由于模拟造成的开销。由于这对于外设组件互连标准（PCI）设备来说通常是必需的，它因此也称为 PCI 透传。由于这些设备中的很多拥有内存映射的接口，它们可以直接读取或者写入主内存，并且因此被称为具有直接内存访问（DMA）能力的设备。为了提供 VM 对于具有 DMA 能力的设备的专属访问，此设备的内存页被映射到客户 VM 的地址空间。随之而来的是由于具有 DMA 能力的设备而造成的威胁。

由于具有 DMA 能力的硬件设备而造成的威胁（HY-DV5）：来自具有 DMA 能力的设备的安全性威胁在于，由于 VM 控制该设备，它可以编程该设备以执行 DMA 操作，指向任意物理（宿主）内存位置，包括属于其他 VM 或者虚拟机监视器的区域 [6]。因此，此类直接设备指认具有破坏 VM 之间的隔离（因而使得由 MMU 强制实施的隔离功能（作为 HY-BF1 的一部分）失去意义）的潜力。

除了上述 3 种类型的设备虚拟化之外，虚拟机监视器宿主还可以支持自虚拟化的硬件设备。这些设备拥有能够导出对应于某种物理功能（PF）的一组虚拟功能（VF）的接口。虚拟机监视器可以随后将这些 VF 指认给多个客户 VM，而它仍然保持对 PF 的控制。这些设备遵守单根 I/O 虚拟化（SR-IOV）规范，并且由此允许具有 DMA 能力的设备在 VM 之间共享（如同虚拟化和多路传输是由这些设备自身实现的）而非如同在透传模式中那样由单一 VM 专用。

2.2.3 针对 HY-BF3 的潜在威胁

上一节呈现了这样一种场景，即准虚拟化，在此，虚拟机监视器必须通过其超级调用接口执行特定指令。关于超级调用的一个潜在的安全性问题在于，缺少对于特定操作的适当的验证（例如，不会验证操作范围，并且因此允许对于 VM 的虚拟机控制块进行完整转储），可能潜在地导致整个虚拟机监视器宿主崩溃。这也是一种设计漏洞，必须通过适当的验证和对相关的虚拟机监视器代码进行测试，而非通过配置或者部署过程来解决。

2.2.4 针对 HY-BF4 的潜在威胁

对于此功能（即 VM 生命周期管理）之下的任务的安全执行的潜在威胁包括：

• 非标准 VM 镜像在库中的存在，包括那些具有过时的 OS 和补丁的镜像，这可能导致任何平台层级的威胁（HYP-T1～HYP-T3）
• 运行着的非标准 VM 实例的存在，由于其基于非标准镜像的创建、从快照恢复、由于监视中的疏忽而导致的对于标准的偏离，以及可能导致任何平台层级的威胁（HYP-T1～HYP-T3）的更新

在大多数实例中，对于 VM 的管理操作是利用通过 GUI 或者脚本环境提交的命令来执行的，二者均由位于后端的管理守护进程支持。上述操作的安全执行通过第 6 章的安全性建议 HY-SR9～HY-SR18 来解决。

2.2.5 针对 HY-BF5 的潜在威胁

此功能之下的任务与虚拟机监视器宿主（即虚拟化的宿主）和虚拟机监视器软件的整体管理相关联，并且通常是通过对用户友好的网页界面或者面向网络的虚拟控制台来执行的。针对这些任务的安全执行的威胁常见于任何远程管理，并且因此并未在此文档中解决。然而，具有虚拟化的宿主的数据中心中的核心要求是拥有对于虚拟机监视器的基于不同判据的统一配置，诸如基于一组托管的 VM 的应用程序的敏感度、业务线，或者云服务环境中的客户端等。因此，这些安全性建议包括一种对于虚拟机监视器配置的中心化管理（HY-SR-19）和一种用于管理流量的专用网段（HY-SR-20）。

某些传统的安全性修补方式对于托管虚拟机监视器的宿主而言可能并不可行。例如，对于针对未被虚拟化的物理服务器的网络攻击，只要关闭发动攻击的端口即可成为阻止该服务器利用机器人攻击向网络发送垃圾信息的解决方案。然而，这样的解决方案对于虚拟机监视器宿主来说并不可行，由于虚拟机监视器宿主的物理网卡的相同端口可能由若干运行着的 VM 所共享。因此，一种特殊的安全性修复，诸如禁用使用这些端口的 VM 的虚拟 NIC 是必需的。

第 3 章 针对整体平台完整性的安全性建议

配置更改、模块版本变化，以及补丁将会影响虚拟机监视器平台组件的内容，诸如 BIOS、虚拟机监视器内核，以及运行于内核中的后端设备驱动程序。为了保证作为虚拟机监视器栈的组成部分的这些组件中的每一个都可信，有必要通过某种能够提供启动完整性的担保的，植根于硬件的证明机制来检测它们的完整性。完整性检测是通过以密码学的方式来认证所启动的虚拟机监视器组件来实现的。这种认证方式验证只有授权的代码可以在系统上运行。具体地，在虚拟机监视器的上下文环境中，这种完整性证明可以防止破坏以及诸如 rootkit 的低级目标性攻击。如果此完整性证明被推迟到某个具有可信权力的作用的可信第三方，此验证过程被称为 可信证明。可信证明提供对于此虚拟机监视器组件的代码未被破坏的证明。在此方式中，对于虚拟机监视器组件的信任是建立在可信硬件的基础之上的。换言之，一条从硬件到虚拟机监视器的信任链是建立在称为 可信根 的首个组件之上的。此服务可以由支持启动完整性测定和证明过程的虚拟机监视器宿主的硬件/固件基础设施来提供。简言之，测定启动环境（MLE）是虚拟机监视器宿主所必需的。

某些硬件平台利用用于测定启动序列中的组件的完整性（通常是二进制代码的散列值）的固件例程来提供对于 MLE 的支持。实施了测定启动过程的基于硬件的密码学存储模块的一个范例是基于标准的可信平台模块（TPM），它已经由可信计算小组（TCG）标准化 [4]。TPM 的 3 个主要组件包括：(a) 测定可信根（RTM）——进行完整性测定（通常是密码学散列值）并且将其转换为证明，(b) 完整性可信根（RTI）——提供受保护的存储、完整性保护，以及受保护的接口以存储和管理证明，以及 (c) 报告可信根（RTR）——提供受保护的环境和接口以管理身份并且签名证明。RTM 沿着启动序列测定下一段代码。此测定结果被存储在称为平台配置寄存器（PCR）的特定寄存器中。

在此，以 TPM 为例简单解释测定启动过程。测定启动过程始于在 BIOS 中执行一段可信的不可变代码，它同样会测定将要执行的下一段代码。在将控制权移交给序列中的下一个程序之前，此测定结果被扩展到 TPM 中的 PCR。由于序列中的每一个组件在移交控制权之前依次测定下一个组件，一条信任链被建立起来。如果测定链持续贯穿整个启动序列，则由此产生的 PCR 值反映了所有组件的测定结果。

证明过程始于请求者调用，通过宿主上的代理，TPM 引用命令。它指定一个证明识别密钥（AIK）以执行对于一组 PCR 的内容的数字签名，该组 PCR 包括启动序列中的所有欲引用的组件的测定结果，以及一个密码学临时随机数以保证数字签名的新鲜度。在接收到签名的引用之后，请求者验证签名并且通过比较 TPM 引用中的测定结果和已知良好的测定结果来决定是否信任所启动的组件。

MLE 可以以如下方式整合到虚拟机监视器宿主中：

• 托管虚拟机监视器的硬件被建立为可信根，一条始于硬件贯穿 BIOS 直到所有虚拟机监视器组件的信任链被建立起来
• 对于想要被建立为可信根并且构建信任链的由处理器和芯片组构成的硬件，它应该拥有支持 MLE 的基于硬件的模块。在支持 MLE 的硬件中启动虚拟机监视器的结果是固件、BIOS，以及虚拟机监视器（内核）模块的全部或者某个关键子集的测定启动，因此构成了从硬件到虚拟机监视器的信任链
• 虚拟机监视器供应必须能够利用 MLE 特性。换言之，虚拟机监视器应该能够调用安全启动过程，这通常是通过向虚拟机监视器的代码库中整合一个前内核模块来实现的，由于内核是在虚拟机监视器启动过程中首个被安装的模块。这个前内核模块的目的是保证选择硬件中的正确的经过认证的模块，该模块对虚拟机监视器中启动的组件或者该硬件上启动的任何软件执行有序的评估或者测定。Tboot 是这样的机制的一个范例，它允许虚拟机监视器利用硬件的 MLE 特性
• 想要成为可信计算基（TCB）的一部分的所有虚拟机监视器组件必须被包括在启用 MLE 机制的范围内，以使得它们作为其启动过程的一部分而被测定

可以撬动虚拟化的宿主的硬件上的带有存储和报告机制的 MLE 特性以提供虚拟机监视器组件的启动完整性担保，通过测定启动序列中的所有实体的身份，从固件开始，然后是 BIOS、虚拟机监视器，以及虚拟机监视器模块，将其与“已知良好值”进行比较；并且报告任何不相符之处。如果该测定启动过程将要被延伸以覆盖 VM 及其内容（客户 OS 和应用程序），在虚拟机监视器内核中的对于基于硬件的 MLE 实现的基于软件的扩展是必需的。现在，对于保证虚拟机监视器平台的所有组件的安全启动过程的安全性建议可以叙述如下：

安全性建议 HY-SR-1：所启动的虚拟机监视器应该成为平台以及整体基础设施的一部分，它包括：(a) 具有基于标准的密码学测定能力和存储设备的支持 MLE 的硬件，以及 (b) 具有提供一条从硬件开始直到所有虚拟机监视器组件的信任链的能力的证明过程。更进一步地，被测定的元素至少应该包括核心内核、内核支持模块、设备驱动程序，以及虚拟机监视器的用于 VM 生命周期管理和虚拟机监视器管理的原生管理应用程序。信任链应该为所有被测定的组件未被破坏并且它们的版本正确（即整体启动完整性）提供担保。如果信任链将要被延伸至客户 VM，虚拟机监视器应该提供一个虚拟接口到基于硬件的 MLE。

第 4 章 HY-BF1 安全性建议

为了保证 VM 中运行的进程的隔离，下列要求必须被满足：

• (a) 从客户 OS 到宿主处理器的高权限命令或者指令必须被调度，以使得 VMM/虚拟机监视器作为虚拟化资源控制器的基本功能得以维持
• (b) 虚拟机监视器宿主的内存管理功能的完整性必须被保护，以防止诸如缓冲区溢出以及非法代码执行等攻击，特别是在存在管理多个 VM 的内存访问所必需的翻译表的情况下
• (c) 内存分配算法必须保证所有 VM 中的负载都能够执行它们的功能
• (d) CPU 分配算法必须保证所有 VM 中的负载都能够执行它们的功能

要求 (a) 和 (b) 可以利用基于软件的模块来满足。然而，相对于基于软件的解决方案，诸如指令集虚拟化和内存虚拟化等基于硬件的虚拟化辅助对于满足这些要求能够提供更多的担保，因而在 4.1 节中被推荐。在表述推荐之前，先简要地讨论一下基于硬件地虚拟化特性。要求 (c) 和 (d) 本意是要保证 VM 中运行的应用程序服务的可用性。用于提供这些保障的是内存分配和 CPU 分配算法中的某些特性，并且与之相关联的配置参数分别在 4.2 和 4.3 节中被表述为推荐。

4.1 硬件虚拟化辅助

指令集虚拟化：用于支持指令集虚拟化的处理器架构提供两种操作模式：root 模式和非 root 模式，每一种都有 4 个层级的权限等级，其中 0 级为最高而 3 级为最低。此外，在这两种模式中，对于执行 CPU 指令，root 模式比非 root 模式具有更高权限。通过在 root 模式中运行虚拟机监视器，并且在高权限或者 0 环的非 root 模式中运行 VM（客户）OS，虚拟机监视器的安全得以保证，至少是通过防止来自任意客户 OS 的任何指令集类型的攻击。然而，VM 逃逸可能通过正常的网络协议而发生。此安全性是通过允许硬件捕获高权限指令以在非 root 模式中运行而在 root 模式中执行而得到保证的。此外，如果虚拟机监视器不必须执行额外的功能（例如利用诸如二进制翻译等技术翻译敏感指令），在虚拟机监视器中以高权限执行的代码将会减少，使得 TCB 更小，并且允许更好的担保验证。

内存虚拟化：如果硬件允许利用基于硬件的页表而非由虚拟机监视器生成的影子页表将客户 OS 在其对应页表中的物理地址映射到宿主的物理地址，则称提供了硬件辅助的内存虚拟化。由此引起的用于执行此功能的高权限代码的减少可以提供相当于上述指令集虚拟化部分所提到的安全性优势。

硬件辅助的虚拟化平台的安全性优势包括以下方面：

• 虚拟机监视器的潜在安全漏洞之一是来自驻留于虚拟化的宿主平台上的 VM 的缓冲区溢出攻击。作为硬件辅助虚拟化的一部分的内存管理（例如扩展页表，PET）的硬件支持可以被撬动以防止来自保留给数据存储的内存位置的代码执行，因此阻止缓冲区溢出攻击
• 虚拟化的硬件扩展提供了两种执行模式：宿主或者 root 模式，以及客户或者非 root 模式。宿主模式运行在高于客户模式的权限等级上。提供基线功能 HY-BF1（处理器分配和内存管理）的虚拟机监视器代码运行于宿主模式而 VM 中的客户 OS 和应用程序运行于客户模式。因此客户 OS 中的任何漏洞利用代码不能破坏由虚拟机监视器代码提供的控制
• 虚拟化平台中的一种常见威胁涉及能够访问属于其他 VM 的内存区域的恶意 VM。这称为 VM 逃逸攻击。具有 IOMMU 的硬件平台提供了针对这种威胁的安全性，通过诸如直接内存访问（DMA）重映射等特性，这将被允许的 DMA 访问限制在指定的保护域中（即阻止设备执行超出其分配区域的 DMA）
• 为两种形式的虚拟化提供硬件辅助的优势在于，虚拟机监视器中的模拟模块可以呈现物理宿主的真实硬件架构而非修改过的硬件架构。这一特性的结果是，未经修改的客户 OS 及其原生设备驱动程序可以运行在 VM 中。启用这一特性的安全性启示是，可用于客户 OS 的 CVE 数据，以及可用于每一种 OS 版本的补丁版本以及认证的设备驱动程序的数量都会显著增加

安全性建议 HY-SR-2：虚拟化的宿主的硬件应该利用 MMU 对指令集虚拟化和内存管理提供辅助，由于硬件支持提供了下列安全性担保，而这些是完全基于软件的虚拟化所不能保证的：

• 更佳的内存管理控制可以防止诸如缓冲区溢出等攻击
• IOMMU 中的 DMA 传输重映射特性提供更佳的 I/O 设备隔离。更进一步地，直接将 I/O 设备指认给某个特定 VM 并且允许直接访问这些资源这一特性消除了为该 VM 提供模拟设备驱动程序的需求，因此减少了可信代码的大小
• 客户 OS 代码和虚拟机监视器代码执行于不同的处理器模式，提供了更佳的隔离
• 权限层级的隔离可以为设备访问调度功能提供更佳的保护，并且硬件层级的内存保护可以提供更佳的 VM 层级保护
• 通过支持完全虚拟化，COTS 版本的 OS 可以允许更简单的补丁和更新，而非必须对可以运行于准虚拟化平台的唯一类型的修改或者移植版本的 OS 进行相同操作
• 由于现在众多虚拟化特性在硬件中可用，虚拟机监视器代码将会变小，允许更佳的安全性证明和验证

4.2 VM 内存分配计划选项

虚拟机监视器的内存调度程序负责在任何时间使得所有 VM 中运行着的所有负载满足其内存要求。类似于 OS，常见的虚拟机监视器利用物理内存和称为虚拟机监视器内核交换文件的交换文件来满足这一要求。更进一步地，常见的 VM 并不总是要求它所被配置的全部内存。基于这些原因，使得运行在某个虚拟化的宿主上的 VM 的配置内存总量超过物理内存总量是一种可能实现的总体虚拟化配置决策，如果 VM 中没有运行内存敏感的应用程序。然而，内存超量使用——即 VM 的配置内存总量和宿主的物理内存的比例——不应过高，由于这可能导致某些要求大量内存的 VM 负载的性能恶化。

对于 VM 中的某些负载，影响虚拟化的宿主或者虚拟机监视器的可用性的另一个因素是物理内存大小和由虚拟机监视器的内存调度程序维护的内核交换文件大小的比例。由于过低的比例将会拒绝某些 VM 中的某些负载的执行，虚拟机监视器中应该有一个配置选项以便为每个 VM 指定一个保证的物理内存量。同样，为了避免这样一种情形，即某个特定 VM 占用了相当于它的全部配置内存的物理内存，应该有一个特性以指定保证的物理内存的上限。最后，可能有某些负载是时间敏感的，则托管它们的 VM 应该相对于其他运行着的 VM 在获得必需的内存资源方面具有一定的优先级。因此，还应该存在一个配置选项以便为每一个 VM 指定一个优先级的值。

基于上述与虚拟机监视器的内存计划相关的问题，下面就是安全性建议：

安全性建议 HY-SR-3：虚拟机监视器应该拥有配置选项以便为每一个要求内存的 VM 指定保证的物理内存量，以及该值的上限，此外还有在多个 VM 之间产生竞争的条件下用于获取必需的内存资源的优先级的值。更进一步地，允许所有 VM 的配置内存总量超过宿主的物理内存的内存超量使用特性应该默认禁用。

4.3 VM CPU 分配选项

VM CPU 分配的安全性目标是保证所有 VM 的可用性。这可以通过对于处理诸如 CPU 内核和 CPU 时钟周期等物理资源的分配的配置选项的适当使用来实现。例如，一个普遍可用的配置选项是设置最小 CPU 要求，或者预留，以时钟周期计算。这里需要遵守的架构参数是，可以被部署的 VM 数量不能超过虚拟机监视器宿主可以提供的 CPU 时钟周期总数和每个 VM 要求的平均预留的比值。例如这样的场景，虚拟机监视器宿主拥有 6000 MHz 的 CPU 能力，而每一个 VM 所要求的平均预留为 1000 MHz，那么该虚拟机监视器宿主上不能有多于 6 个 VM 处于活动状态。因此，预留为每个 VM 所要求的 CPU 时钟周期设置了下限（保证）。类似地，还应该有一个特性来为每一个 VM 所能够使用的 CPU 周期设置上限，或者限制，以使得没有一个 VM（有时是恶意或者受到攻击的 VM）会消耗宿主的全部 CPU 资源并且对与之共同驻留的 VM 拒绝服务。更进一步地，为了在这样一种情况下辅助计划虚拟机监视器宿主的 CPU 时钟周期，即多个 VM 要求的时钟周期高于下限但是低于上限，应该有一个特性来为每一个 VM 指认一个优先级分值，或者份额。综合以上关于保证所有部署的 VM 之间的合理分配的理想特性，关于 VM CPU 分配的安全性建议如下所述：

安全性建议 HY-SR-4：虚拟机监视器应该拥有强壮的配置特性以用于将虚拟资源提供给所有托管的 VM，以使得它不会超过某种关键物理资源（例如 CPU 内核数量）

安全性建议 HY-SR-5：虚拟机监视器应该提供特性以便为每一个部署的 VM 所需的 CPU 时钟周期指定下限和上限，以及提供特性以便为每一个 VM 指定一个优先级分值，以便在多个 VM 竞争 CPU 资源的情况下辅助计划

第 5 章 HY-BF2 安全性建议

关于 2.2.2 节所讨论的所有 3 种形式的设备虚拟化以及自虚拟化的设备的讨论于本节提供。

安全性建议 HY-SR-6A（模拟）：由于通过软件模拟硬件的复杂性，模拟方式除了受到性能损失以外，还会增加 TCB 的大小，特别是在客户 OS 拥有原生设备驱动程序并且设备模拟代码作为内核模块运行在和虚拟机监视器相同的权限层级的情况下。因此，模拟应该仅被应用于这种复杂性可控时（例如 USB 主机控制器）

安全性建议 HY-SR-6B（准虚拟化）：在准虚拟化的设备驱动程序被用于 VM 中的情况下，对物理设备的访问的调度应该通过在专用 VM 而非在虚拟机监视器中运行后端设备驱动程序（它们控制着连接到虚拟机监视器宿主的物理设备）来启用。这有助于使得后端设备驱动程序代码运行在低于虚拟机监视器的权限层级上。此外，虚拟机监视器平台应该包括输入/输出内存管理单元（IOMMU）形式的硬件支持以便验证并且翻译从驱动程序域的底层硬件设备到宿主内存的访问。强制性的具体 IOMMU 特性包括 DMA 重映射，在此，从设备到客户物理地址（GPA）的 DMA 调用必须被翻译到宿主物理地址（HPA），并且随后被检查该 HPA 地址是否落在指认给该设备的保护域内。结合这些机制可以减少 TCB 的大小，并且降低错误的设备或者设备驱动程序的行为的影响（限制在设备驱动程序 VM 范围内，而非虚拟机监视器）

安全性建议 HY-SR-6C（透传或者自虚拟化的硬件设备）：对于 VM 需要被赋予对具有 DMA 能力的设备的专用访问权限的情况，虚拟机监视器平台应该包括输入/输出内存管理单元（IOMMU）形式的硬件支持以便验证并且翻译所有设备对宿主内存的访问。此建议也适用于自虚拟化的硬件设备的使用（基于 SR-IOV 规范）。强制性的具体 IOMMU 特性包括 DMA 重映射，在此，从设备到客户物理地址（GPA）的 DMA 调用必须被翻译到宿主物理地址（HPA），并且随后被检查此 HPA 是否落在指认给该设备的保护域内

下列安全性建议的适用性与设备虚拟化的类型无对应关系：

安全性建议 HY-SR-7（设备访问）：应该可能设置访问控制列表（ACL）以便将每一个 VM 进程的访问权限限制为仅对指认给该 VM 的设备。为了实现这一点，虚拟机监视器配置应该支持某种特性以标记 VM（从语义上讲，一组任务），并且/或者拥有某种特性以便为每一个 VM 指定一组白名单，或者被允许的设备的列表

安全性建议 HY-SR-8（设备使用）：应该可能为每一个 VM 的网络带宽和 I/O 带宽（例如硬盘读/写速度）设置资源限制以防止拒绝服务（DOS）攻击。此外，对资源限制的适当使用可以使得 DOS 攻击对定义了资源限制的 VM 或者集群的影响定域化

第 6 章 HY-BF4 安全性建议

6.1 VM 镜像管理

由于基于 VM 的软件（例如客户 OS、中间件和应用程序）利用虚拟机监视器软件共享虚拟化的宿主的物理内存，并不令人惊讶的是，VM 是所有指向虚拟机监视器的攻击的最大来源。在操作中的虚拟化环境中，VM 很少是从头构建的，而是从 VM 镜像构建。VM 镜像是用于创建运行着的 VM 版本的模板。某个组织机构可以拥有其自身的判据以便在其 VM 库中对其使用的不同 VM 镜像进行分类。一些常用的判据包括：处理器负载（用于计算密集型应用程序的 VM）；内存负载（用于诸如数据库处理等内存密集型应用程序的 VM）；以及应用程序敏感度（运行使用关键任务数据的关键任务应用程序的 VM）。对于每一种 VM 镜像类型，必须遵循下列实践以保证所得到的运行中的 VM 是安全的：

• 对于每一种 VM 镜像类型的黄金镜像文档。黄金镜像是由一组与 VM 镜像相关联的配置变量定义的。这些配置变量至少应该包括：客户 OS 厂商、版本、补丁级别、创建日期、vCPU 内核数量，以及内存大小等
• VM 镜像库中的每一个 VM 镜像必须带有与之相关联的数字签名
• 对 VM 镜像库的访问权限必须通过某种强壮的访问控制机制加以控制
• 对存储 VM 镜像的服务器的访问应该拥有安全协议

与上述实践相关联的安全性建议如下所述：

安全性建议 HY-SR-9：必须为所有类型的 VM 定义黄金标准，并且不符合此标准的 VM 镜像不应该被允许存储到 VM 镜像服务器或者库中。VM 镜像库中的镜像应该被周期性地扫描以查找过时的 OS 版本和补丁，这可能导致偏离标准

安全性建议 HY-SR-10：存储于镜像服务器中的每一个 VM 镜像应该带有数字签名以作为合法性和完整性的标识，利用可信、强壮的密码学密钥签名

安全性建议 HY-SR-11：向 VM 镜像库中迁入或者从中迁出镜像的许可应该通过某种强壮的访问控制机制强制实施，并且限制在一组授权的管理员中。如果没有访问控制机制，VM 镜像文件应该存储于加密设备中，该设备只能由一组限定的授权管理员利用具有足够复杂度的口令打开或者关闭

安全性建议 HY-SR-12：对存储 VM 镜像的服务器的访问应该总是通过安全协议，诸如传输层安全性协议（TLS）

6.2 VM 即时迁移

即时迁移是一种存在于所有虚拟机监视器中的功能，它允许某个 VM 被从一个虚拟化的宿主上迁移到另一个上，而其上的客户 OS 和应用程序仍然在运行。此功能提供了如下的关键优势：容错性、负载均衡，以及宿主维护、升级和补丁。在即时迁移中，源宿主上的客户 OS 的状态必须被复制到目标宿主上。这要求迁移内存内容、处理器状态、存储（除非两个宿主共享同一存储）以及网络状态

大多数虚拟机监视器所采用的最常见的内存迁移技术称为 预复制。在此方式中，属于 VM 的内存页被传输到目标宿主，而此 VM 继续在源宿主上运行 [5]。在迁移过程中被修改的内存页被再次发送至目标以保证内存一致性。在此阶段中，VM 上的当前正在操作中的所有处理器寄存器的精确状态也被传输过去，并且正在迁移中的 VM 在源宿主上挂起。目标的处理器寄存器被修改以复制源的状态，并且新迁移的 VM 恢复其操作。存储迁移由这样一种特性提供，它允许管理员将 VM 的文件系统从一个存储位置移动到另一个，而没有停机时间。这种存储迁移甚至可以发生在没有 VM 迁移的情况下，例如，某个 VM 可以继续在宿主服务器上运行，与此同时，构成此 VM 的文件在存储阵列或者逻辑单元号（LUN）之间移动。

在上述过程中，内存和处理器状态迁移功能是虚拟机监视器设计的内在方面，而存储迁移功能是存储管理的组成部分，并且适用于虚拟化和非虚拟化的基础设施。网络状态在 VM 迁移之后得以维持，由于每个 VM 带有其自身的独特 MAC 地址，并且迁移过程为迁移目标施加了某些限制（例如源和目标宿主应该位于相同的 VLAN 中）。因此，从安全维护的角度来看，唯一需要考虑的方面就是迁移过程的适当认证和安全的网络路径。

安全性建议 HY-SR-13：在 VM 即时迁移过程中，必须使用安全认证协议；执行迁移操作的管理员的凭证只被传输至目标宿主；内存内容和处理器状态的迁移通过安全网络连接进行；并且一个专用虚拟网段被同时用于源和目标宿主以承载此流量

6.3 VM 监视与安全策略强制实施

由于 VM 是针对虚拟机监视器的威胁的主要来源，针对 VM 状态和这些 VM 的出入流量的不间断监视是必要的，对于：(a) 控制流量类型，(b) 入侵检测和预防，以及 (c) 检测病毒和其他恶意软件。此功能可以通过两种方式实现：

• 基于 VM 的安全监视和介入解决方案
• 在 VM 或者虚拟网络对象（即虚拟交换机的端口/端口组）层级上的由具有流量规则强制实施功能的虚拟机监视器模块实现的安全监视和介入

在基于 VM 的安全监视和介入的方式中，软件或者软件代理（即安全工具）运行在某个 VM 之中以监视安全相关事件。此方式类似于运行基于宿主的 IDS。此方式的优势在于它对于运行在 VM 之中的代码提供了良好的可视性和上下文分析。然而，由于依赖底层客户 OS 上的安全工具，任何针对后者的攻击也会破坏此安全工具的功能，因此破坏这种反制措施。将安全工具作为可视化负载运行的另一个缺点是它对于其自身以及该 VM 上运行的其他应用程序负载的性能影响。

基于虚拟网络的安全监视 可以有两种形式：

• (a) 用于保护每一个 VM 的专用安全设备
• (b) 运行在虚拟网络中并且能够保护虚拟机监视器宿主中的多个 VM 的安全设备

专用的安全设备在虚拟网络中被部署在被监视的 VM 之前，并且监视出入该 VM 的全部流量。此方式的主要缺点是，如果该 VM 被迁移至其他物理宿主，此专用设备也必须被迁移。

部署在虚拟网络上并且被配置为监视多个 VM 的通用安全设备可能必须被不间断地重新配置，由于下列原因：

• 被监视的该组 VM 总是不间断地处于某种状态流中，由于 VM 会被从一个虚拟化的宿主迁移到另一个，由于负载均衡、性能，甚至是安全性的原因
• 如果虚拟局域网（VLAN）被用于在 VN 之间提供通讯层级的隔离，VLAN 的配置可能随着 VM 上的负载结构偏移而发生持续的更改，着可能要求重新配置网络流量镜像能力以保证所有虚拟网络流量流经影响着该虚拟化的宿主上的负载的总体性能的监控工具

在基于虚拟机监视器的安全监视解决方案中，监视并保护 VM（用户 VM）的安全工具运行在托管业务应用程序的 VM 之外，而是在某个安全加固的特殊 VM 中。被设计并且配置为运行在此种模式下的安全工具称为安全虚拟设备（SVA）。SVA 通过虚拟机监视器中的 虚拟机自省 API 获得对于 VM 状态（例如 CPU、寄存器、内存和 I/O 设备）以及虚拟机之间、虚拟机和虚拟机监视器之间的网络流量的可视性。这是理想的解决方案，由于：

• (a) 它不易受到客户 OS 中的瑕疵的攻击
• (b) 它独立于虚拟网络配置，并且每当虚拟网络配置由于 VM 迁移或者驻留于该虚拟机监视器宿主上的 VM 之间的连接性的改变而发生改变时，不必须重新配置它

因此，对于为了保护虚拟机监视器而创建的 VM 监视解决方案的安全性建议如下所述：

安全性建议 HY-SR-14：应该存在机制以用于安全监视、VM 操作安全策略强制实施，以及检测 VM 中运行的恶意进程和出入 VM 的恶意流量。此监视和强制实施机制构成了用于构建杀毒（AV）和入侵检测及防止系统（IDPS）解决方案的基础

安全性建议 HY-SR-15：用于 VM 的安全监视和安全策略强制实施解决方案应该基于 VM 外部，并且撬动虚拟机监视器的虚拟机自省能力。通常，这样的解决方案涉及在安全加固的或者可信 VM 中运行诸如安全虚拟设备（SVA）的安全工具

安全性建议 HY-SR-16：运行于虚拟机监视器宿主中的所有反恶意软件工具（例如查毒软件、防火墙和 IDPS 等）应该拥有能力以执行基于一定周期的自主签名或者索引文件更新

6.4 VM 配置管理

每一个 VM 的配置都应该被监视和管理，贯穿其生命周期。在大多数案例中，除了虚拟机监视器自带的原生特性以外，这还可以通过利用专用的第三方工具来实现。这些工具的理想特性以安全性建议的形式提供如下：

安全性建议 HY-SR-17：VM 配置管理工具应该具有能力以编译日志并且警示管理员，如果在被监视的任何 VM 中检测到配置更改

6.5 用于 VM 管理的精细粒度管理权限

拥有能力以对虚拟化的基础设施指认精细粒度的管理权限使得建立不同的管理模型及其相关授权机制成为可能。为了展示对于粒度许可的要求，检视用于虚拟化的基础设施中的管理操作的一些应用案例场景是有帮助的：

• VM 管理应用案例 1：某个质量保证团队想要设置少量具有某些限定特性（诸如内存、CPU 等资源限额）的虚拟机以测试某些即将进入生产的应用程序。在此情况下，出于测试目的，在质量保证团队中专门指派一位或者更多位管理员以被授予特定的虚拟机设置的管理权限可能会有用
• VM 管理应用案例 2：某位被指派了确定不同虚拟化的服务器上的操作负载和对额外的虚拟化的宿主的需求的任务的性能规划者可能需要权限以查看每一个虚拟化的宿主中的虚拟机的列表，而非需要对这些 VM 执行任何管理操作的权限。在此情况下，拥有能力以授予对于虚拟化的宿主中的 VM 列表的查看权限，但是拒绝此用户与任何可见的对象的交互的权限是理想的
• VM 管理应用案例 3：在具有不同敏感度等级的 VM 运行于同一虚拟化的宿主之上的虚拟化的数据中心中，某位在虚拟机监视器层级被授予管理权限的管理员有时应该被禁止访问某个特定 VM，由于运行在该 VM 上的负载（即应用程序集合）的敏感性本质。在此情况下的理想能力是对于某个特别的子对象，拒绝其通过继承获得的权限
• VM 管理应用案例 4：在某些情况下，对一组为某个特定组织分部或者部门控制一系列 VM 的管理员指认权限是必需的。此类管理实体的必然结果是对于一类想要管理运行着某种特定类型的负载（例如网络服务器）的 VM 的管理员的需求，无论其在组织结构中的位置。此类管理员可能并不要求对于某个 VM 的全套管理功能，而只是某些管理功能的任意集合，诸如配置 CD 介质、配置软盘介质、控制台交互、设备连接、开机、关机、重置，或是挂起等。此场景要求具有能力以创建自定义功能，即它可以包括与某个 VM 相关联的权限的任意集合，也需要具有能力以创建自定义对象，即它可以包括运行某种特定类型的负载（例如网络服务器）的 VM 的任意集合

综合所有 4 种管理场景中的能力要求，关于必需的权限粒度的总体安全性建议如下所述：

安全性建议 HY-SR-18：用于 VM 管理的访问控制解决方案应该拥有粒度能力，既在权限授予层级，也在对象层级（即对于权限目标的具体说明可以是单一 VM 或者任何 VM 的逻辑组合，基于功能或者位置）。此外，还应该存在这样的能力以禁止对于某个 VM 组（例如运行具有特定敏感度等级的负载的 VM）中的某些特别对象的权限，尽管其拥有对于该 VM 组的访问权限

第 7 章 HY-BF5 安全性建议

对于任何服务器级别的软件而言，管理功能的安全选项都是至关重要的，虚拟机监视器也不例外。其结果是一种能够提供对抗安全侵犯所必需的保护的安全配置。在虚拟机监视器的案例中，相对于众多服务器软件实例，非安全配置的影响可能更加严重，由于针对虚拟机监视器的攻击可能导致针对其上运行着的众多 VM 的攻击。尽管配置参数的组成取决于虚拟机监视器供应的设计特性，对于每一个独立的参数的值的选择的纬度会产生不同的配置选项。众多配置选项与功能特性和性能相关。然而，有一些选项对于虚拟机监视器的安全执行具有直接影响，并且这些就是此文档中所讨论的配置选项。

以下是一些通用于任何服务器级别的软件的安全实践。尽管也适用于虚拟机监视器，这些并未在此文档中解决：

• (a) 虚拟机监视器宿主本身上的管理帐户控制以及对不同管理员的最小权限指认
• (b) 虚拟机监视器软件和宿主 OS 的补丁管理
• (c) 通过诸如 TLS 或者 Secure Shell（SSH）等安全协议同虚拟机监视器进行通讯

7.1 中心化管理

对虚拟机监视器和虚拟机监视器宿主的管理可以通过两种方式实现：

• 在每一个虚拟机监视器宿主中设置有管理帐户
• 通过企业虚拟化管理软件对所有虚拟机监视器和虚拟机监视器宿主进行中心化管理

通过企业虚拟化管理软件（EVMS）对企业中的所有虚拟机监视器平台进行中心化管理是理想的，由于用于企业中的所有虚拟机监视器的一组黄金标准配置可以通过 EVMS 定义并且简单地强制实施。对于任何想要高效运行的 IT 数据中心，实施负载均衡和容错措施是必要的，这可以通过定义虚拟机监视器集群来实现。对集群的创建、指派应用程序负载以及管理只能依靠中心化的管理软件来实现，使得部署和使用企业虚拟化管理软件成为强制性的。

因此，对于虚拟机监视器管理架构的建议如下所述：

安全性建议 HY-SR-19：对于企业中安装的所有虚拟机监视器的管理应该利用企业虚拟化管理系统（EVMS）以中心化的方式实现。用于不同类型的负载和集群的企业黄金标准虚拟机监视器配置必须通过 EVMS 进行管理和强制实施。此黄金标准配置至少应该覆盖 CPU、内存、存储、网络带宽，以及如有必要，宿主 OS 加固

7.2 保护管理网络

为了将多个 VM 彼此连接起来，以及将它们连接到虚拟化的宿主作为其中一个结点的企业网络，虚拟机监视器通过其管理控制台或者命令行界面（CLI）允许一种由软件定义的通讯结构，或者虚拟网络。此能力可以由专用的管理 VM 提供，也可以直接在虚拟机监视器内核中通过内核模块来提供。虚拟网络是一种由软件定义的人造物，它完全驻留于虚拟化的宿主中，并且拥有驻留于其中的 VM 作为其结点。此虚拟网络的组件包括：(a) 为每一个 VM 定义并且提供每一个 VM 到虚拟网络的连接的虚拟网卡（vNIC）；(b) 在 VM 之间提供选择性的连接性，并且其配置决定了虚拟网络拓扑结构的虚拟交换机；以及 (c) 提供 VM 到企业网络的连接性的虚拟化的宿主的物理网卡（pNIC）。

在考虑虚拟网络的安全性影响时，下列 3 项主要功能必须被考虑到：

• 在属于不同逻辑分组（例如，在基础设施即服务（IaaS）的云服务案例中的不同租用者；诸如网络服务器或者数据库服务器中的不同应用层；或者企业中的不同业务线应用程序等）的 VM 组别中提供选择性的连接性或者隔离
• 设置专用的子网用于关键功能，诸如 (a) 出于安全性或者性能的原因，将 VM 从一个虚拟机监视器宿主迁移到另一个，(b) 连接基于网络的存储设备，以及 (c) 容错性日志
• 在管理 VM（虚拟网络的一个结点）中提供对管理接口的访问，此管理 VM 被用于执行 VM 生命周期管理（HY-BF4）和虚拟机监视器平台管理（HY-BF5）的虚拟机监视器关键基线功能

在上述 3 种功能之中，VM 组别之间的选择性的连接性和隔离对于为运行在这些 VM 上的应用程序提供安全性是必需的，因此超出了此文档的范围。同样的判据适用于设置专用的子网用于基于网络的存储管理。我们已经在第 6 章讨论了 VM 生命周期管理之下的安全 VM 迁移。因此，我们对于虚拟网络配置的专注限于为用于执行 VM 管理和虚拟机监视器管理功能的网络接口提供保护。一种被普遍采用的方式是分配一块专用的物理网卡（NIC）用于处理管理流量，如果这不可行，则改为专用于此功能的虚拟网段（vLAN ID）。

安全性建议 HY-SR-20：对于虚拟机监视器宿主和软件管理功能的保护应该通过分配一块专用的物理 NIC 来保证，如果这不可行，则改为将虚拟机监视器的管理接口置于专用的虚拟网段中，并且利用防火墙强制实施流量控制（例如，在企业网络中指定子网，从这些子网到管理接口的流入流量被允许）

第 8 章 安全性建议总结

虚拟机监视器是一种复杂的服务器级别的软件，它通过虚拟化硬件资源以允许执行多个具有各异 OS 的计算栈（VM）以及托管于其中的多个应用程序。对于虚拟机监视器及其物理宿主（即虚拟机监视器宿主或者虚拟化的宿主）的安全配置被总体性地称为虚拟机监视器平台，并且对于为关键任务应用程序的执行提供安全平台是必需的。

由于存在多种方式对虚拟机监视器架构进行分类，此文档中所采用的方式是识别虚拟机监视器所执行的 5 项基线功能、每一项基线功能所涉及的任务、该任务的安全执行的潜在威胁，以及对以安全性建议的形式给出的，能够提供担保以对抗利用这些威胁的反制措施进行表述。

从总体上看，为虚拟机监视器的安全部署提供了 20 项安全性建议。除了两项（HY-SR-1 和 HY-SR-2）以外，都与虚拟机监视器平台中的软件模块的配置参数相关。这些参数包括软件模块（例如设备驱动程序和 VM 镜像）的完整性度量，访问控制（例如设备访问、VM 镜像访问和 VM 管理）的设置，以及安全协议（例如 VM 镜像服务器的访问和 VM 迁移）的配置。这些安全性建议同虚拟机监视器的基线功能之间的对应关系于附录 B 提供。

此文档中概述的信任模型（参见 1.2 节）假设虚拟机监视器宿主的硬件可信。然而必须指出的是，已有被报导的攻击案例（例如与某些被隐式共享的硬件资源，诸如 CPU 缓存和转译后备缓冲器（TLB），相关的旁路攻击）。更近时期公开的与 CPU 层级的性能优化相关的攻击（例如 Spectre 和 Meltdown）同样限制了对于当前用于虚拟机监视器部署的硬件平台的信任的担保。

附录 A 虚拟机监视器基线功能描述

关于 5 种虚拟机监视器基线功能中的每一种的详细描述提供如下：

• HY-BF1：VM 进程隔离——提供 VM 执行计划，管理在 VM 中运行的应用程序进程，诸如 CPU 和内存管理，以及在 VM 中运行应用程序的过程中进行不同的处理器状态之间的上下文切换。如果具有 DMA 能力的设备被用于虚拟机监视器宿主，这些设备的内存访问也需要被控制。然而，此功能被认为属于 HY-BF2，由于它属于设备调度。
• HY-BF2：设备调度和访问控制——使设备对于 VM 可用（例如通过模拟、准虚拟化、透传或者自虚拟化的硬件设备），并且控制哪些 VM 被允许访问哪些设备（例如网卡（NIC），诸如 IDE 驱动器的存储设备等）。
• HY-BF3：来自客户 VM 的命令的直接执行——某些来自客户 OS 的命令是由虚拟机监视器直接执行的，而非通过中断或者上下文切换而触发。此功能适用于那些实现了准虚拟化而非完全虚拟化的虚拟机监视器。
• HY-BF4：VM 生命周期管理——这涉及从 VM 镜像的创建和管理、VM 状态的控制（开始、暂停、停止）、VM 迁移、制作快照、VM 监视，到策略的强制执行等全部功能。
• HY-BF5：虚拟机监视器平台的管理——这涉及定义虚拟机监视器软件模块中的不同配置参数中的一些东西和设置值，包括适用于虚拟机监视器中的虚拟网络的配置的东西和设置值。

关于上述基线功能的详细描述如下：

A.1 HY-BF1（VM 进程隔离）

提供 VM 执行计划，管理在 VM 中运行的应用程序进程，诸如 CPU 和内存管理，以及在 VM 中运行应用程序的过程中进行不同的处理器状态之间的上下文切换。为了保证 VM 进程隔离，来自支持 DMA 的设备的内存访问也需要受到虚拟机监视器的控制（例如通过 IOMMU）。然而，此功能被认为属于 HY-BF2，由于它属于设备调度。

A.2 HY-BF2（设备调度和访问控制）

在 VM 中执行的应用程序需要访问诸如网络和存储设备。对设备访问的调度在虚拟机监视器宿主中通过设备虚拟化（也称为 IO 虚拟化）来处理。有 3 种常见的设备虚拟化方式：(a) 模拟，(b) 准虚拟化，和 (c) 透传或者自虚拟化的硬件设备。

在模拟中，代码被如此实现以呈现某个虚拟设备，它拥有与之对应的真实（硬件）设备，客户 OS 已经拥有它的驱动程序。这允许运行未经修改的客户（VM），由此实现完全虚拟化。模拟代码运行于虚拟机监视器中。来自客户 VM 应用程序（通过其客户 OS）的 I/O 调用被虚拟机监视器内核拦截，并且转发到此代码，由于客户 VM 在此设置之下不能直接访问物理设备。这也可以将来自客户 VM 的模拟虚拟设备的访问多路传输至底层物理设备。

在准虚拟化方式中，虚拟机监视器向客户呈现某个人工设备的某个接口，此设备没有相应的硬件对应体。这允许在客户上安装特定的，简化的，对虚拟机监视器警觉的 I/O 驱动程序（称为准虚拟化的驱动程序）。来自客户 VM 中的这些准虚拟化的设备驱动程序的调用由另一个设备驱动程序（称为后端驱动程序）来处理，这些驱动程序直接与物理设备交互，并且调度来自准虚拟化的客户到该物理设备的访问。在某些实例中，来自准虚拟化的客户驱动程序的调用直接由虚拟机监视器通过其超级调用接口（与之相对应的调用称为超级调用）来处理。

设备虚拟化的第 3 种方式，透传方式（或者直接设备指认）被部署于这样的情形，在此，由于性能的原因，某个 VM 需要对于某个设备（例如 NIC、硬盘控制器、HBA、USB 控制器、串口、火线控制器、声卡等）的专属访问，以避免由于模拟造成的开销。通常，这对于 PCI 设备来说通常是必需的，并且因此也称为 PCI 透传。由于这些设备中的很多拥有内存映射的接口，它们可以直接读取或者写入主内存，并且因此被称为具有直接内存访问（DMA）能力的设备。为了提供 VM 对于具有 DMA 能力的设备的专属访问，此设备的内存页被映射到客户 VM 的地址空间。

除了上述 3 种类型的设备虚拟化之外，虚拟机监视器宿主还可以支持自虚拟化的硬件设备。这些设备拥有能够导出对应于某种物理功能（PF）的一组虚拟功能（VF）的接口。虚拟机监视器可以随后将这些 VF 指认给多个客户 VM，而它仍然保持对 PF 的控制。这些设备遵守单根 I/O 虚拟化（SR-IOV）规范，并且由此允许具有 DMA 能力的设备在 VM 之间共享（如同虚拟化和多路传输是由这些设备自身实现的）而非如同在透传模式中那样由单一 VM 专用。

A.3 HY-BF3（来自客户 VM 的命令的直接执行）

某些来自客户 OS 的命令是由虚拟机监视器直接执行的，而非通过中断或者上下文切换而触发。这些命令称为超级调用，并且由虚拟机监视器中的特殊接口支持。此功能仅适用于那些实现了准虚拟化而非完全虚拟化的虚拟机监视器。

A.4 HY-BF4（VM 生命周期管理）

这包括 VM 上的所有管理操作，贯穿其生命周期。它们包括但不限于：

• 遵守标准镜像的 VM 创建，保证镜像的完整性并且保护镜像的存储和获取过程；供应具有适当的 vCPU、内存、网络和存储的镜像
• 将 VM 从一个虚拟机监视器宿主迁移到另一个
• 监视 VM 执行与出入流量，以及总体配置管理
• 对于 VM 管理的精细粒度访问控制，包括改变 VM 状态的基本操作——启动、暂停、停止
• 快照的访问控制和管理

管理任务通过利用提供了网络接口的管理守护进程而实现。这些接口通常不是作为虚拟机监视器内核模块的一部分，而是在高权限 VM（管理 VM）上实现，它作为虚拟机监视器平台启动过程的一个组成部分而启动。

A.5 HY-BF5（虚拟机监视器平台管理）

这些任务包括虚拟机监视器宿主（虚拟化的宿主）和虚拟机监视器软件本身的配置所涉及的任务。重要的任务包括：将 VM 供应至虚拟机监视器宿主，创建和管理虚拟机监视器集群，以及配置虚拟机监视器宿主内部的虚拟网络。虚拟网络是虚拟机监视器宿主内部的由软件定义的网络，它允许 VM 之间的连接性，以及 VM 到外部网络（例如 LAN、WAN 等）的连接性。

附录 B 关于虚拟机监视器的基线功能的安全性建议的可溯源性

附录 C 用语

• 完全虚拟化——一种形式的虚拟化，其中，虚拟机监视器呈现的虚拟化资源反映了底层硬件的架构，因此未经修改的客户 OS 可以在其上运行
• 客户操作系统（OS）——虚拟机（见下）执行栈中的操作系统组件，其他组件包括虚拟硬件、中间件和应用程序
• 虚拟机监视器——利用某种特殊的 OS 内核以及支持性的内核模块构建的软件，这些内核模块为虚拟机（见下）所呈现的不同执行栈提供隔离
• 虚拟化的宿主——诸如虚拟机监视器等虚拟化软件所安装于其上的物理宿主。通常，虚拟化的宿主将会包含特别硬件平台以辅助虚拟化——特别是指令集和内存虚拟化
• 虚拟机（VM）——由软件定义的完整的执行栈，由虚拟化的硬件、操作系统（客户 OS）和应用程序构成
• 虚拟化——用于硬件资源模拟或者抽象化的方法，以允许完整的执行栈，包括软件应用程序，在其上运行

附录 D 参考文献

• 1. Mastering VMware vSphere 5.5, Scott Lowe et al., Wiley Publishing Incorporated (2013)
• 1. Running Xen: A Hands-On Guide to the Art of Virtualization, J.N. Matthews et al., Prentice Hall (2008)
• 1. Building the Infrastructure for Cloud Security: A Solutions View, R.Yeluri, and E.Castro-Leon, Apress Media/Springer Science (2014)
• 1. Trusted Platform Module (TPM) Main Specification: http://www.trustedcomputinggroup.org/resources/tpm_main_specification
• 1. S.Shirinbab, L. Lundberg and D. Ilie, Performance Comparison of KVM, VMware and Xenserver using a Large Telecommunication Application, Proceedings of the Fifth International Conference on Cloud Computing, GRIDs, and Virtualization (CLOUD COMPUTING), 2014. http://bth.diva-portal.org/smash/record.jsf?pid=diva2%3A834000
• 1. E. Bugnion, J. Nieh and D. Tsafrir, Hardware and Software Support for Virtualization,