基于虚拟化的红绿隔离安全架构

为安全敏感应用高效构建可信环境

摘要

我们提出了一种方法，为用户提供一个可信的安全环境，以运行其安全敏感应用。我们的解决方案将用户应用程序运行在不同的虚拟机（VM）中：安全敏感应用运行在可信绿色虚拟机中，而其他应用则运行在不可信红色虚拟机中。我们使用硬件虚拟化机制隔离这两个虚拟机，并交替运行它们。这有助于实现更小的虚拟机监视器、更安全的虚拟机隔离以及为绿色虚拟机提供可信I/O通道。虚拟机之间的切换基于ACPI S3睡眠事件。绿色虚拟机的可信性通过其精简且受限的软件栈以及启动时的完整性证明得以维持。我们重点通过为绿色虚拟机采用无状态策略来降低红绿虚拟机切换时间：使用RAM磁盘，并在每次执行红绿虚拟机切换时将其恢复至原始状态。我们在启动时将绿色VM的镜像加载到内存中，并为绿色虚拟机预留内存空间。这使得切换时间降低至约18秒。

关键词 ：虚拟化 · Red/green虚拟机 · Isolation ·保护 · Integrity · Trusted path · Fast切换

1 引言

我们的目标是保护安全敏感的用户操作，例如在互联网浏览器中对电子银行/电子商务网站进行交易。在这种情况下，用户必须信任其系统至关重要。保护终端用户系统的安全并非易事。将安全工具置于用户系统内部的传统方案已被证明效果不佳，原因在于底层操作系统存在大量漏洞。

一种最受认可的替代方法依赖于虚拟化[4]以更好地将安全工具与用户系统隔离。原始用户系统在虚拟机（VM）中运行，而安全工具则位于该VM之外，要么位于另一个专用VM中，要么位于虚拟化系统内部，即虚拟机监控器（HV）中。虚拟机监控器隔离并保护各个虚拟机，并为安全工具提供透明控制用户VM的机制。

一种基于虚拟化的安全工具使用内省[3]受保护的虚拟机。内省面临的主要问题是语义鸿沟。提出的各种解决方案要么缺乏通用性，要么缺乏精确性。内省还会引入性能开销，这对于所有类型的用户应用程序来说都是不可接受的。

另一种方法根据用户应用程序的安全需求将其划分为不同的类别，并在不同的虚拟机中运行：

1. 一种红色虚拟机，对可运行的用户应用程序、可执行的操作以及可访问的远程服务均不施加限制。该红色虚拟机暴露了较大的攻击面，因此被视为不可信的，并作为不可信环境（尽管功能丰富）用于运行安全不敏感应用。
2. 一个绿色虚拟机，对可运行的用户应用程序及其可执行的操作施加严格的安全限制。该绿色虚拟机暴露的攻击面更窄。此外，其完整性可在启动时进行度量和证明，并可使用专门的安全工具对其进行保护。所有这些措施使得该绿色虚拟机被视为可信的，并作为可信环境（尽管功能受限且定义明确）来运行安全敏感应用。

红色和绿色虚拟机有两种不同的使用方式。

同时运行这两个虚拟机concurrently[8]使用户能够同时使用两种类型的应用程序，具有明显优势。然而，这种策略增加了绿色虚拟机的攻击面：首先，由于需要虚拟化两个虚拟机之间共享资源，导致虚拟机监控器的复杂性和规模增加；其次，资源共享会打开诸多侧信道，难以完全关闭。此外，确保用户与绿色虚拟机之间的I/O通道的隐私和安全性也较为困难[11]。

交替运行两个虚拟机alternatively[15]几乎完全消除了侧信道攻击，并显著降低了虚拟机监控器的复杂性和规模，同时硬件资源无需虚拟化，因为它们被直接分配给唯一正在运行的虚拟机。只要仅由当前运行的虚拟机控制和使用I/O设备，该方法还使得为用户与绿色虚拟机之间建立可信I/O通道变得简单直接。然而，这种策略的主要问题是虚拟机之间的切换时间相对较长，通常在几十秒的范围内[15]。尽管如此，从用户的角度来看，只要他们普遍愿意以时间换取安全性，特别是当安全敏感应用不频繁运行时，这可能是可以接受的。

我们决定开发一种基于交替运行两个虚拟机的解决方案。我们的虚拟机监控器利用硬件虚拟化支持来实现对绿色虚拟机的隔离和保护。与其他方案类似[9,14]，我们的目标是构建一个轻量级、专用于安全的虚拟机监控器。我们使用ACPI睡眠事件以非侵入且透明的方式在虚拟机之间进行切换。

我们的解决方案相较于通用方法的主要贡献在于：
– 通过以下方式获得从红色虚拟机到绿色虚拟机的更短切换时间：(1) 准备一个较小的绿色虚拟机镜像，减少其软件栈
一个简化的操作系统和仅受保护的用户应用程序，(2) 在绿色VM的镜像中保存部分系统快照，(3) 在虚拟机监控器启动时将绿色VM的镜像加载到内存中（避免从硬盘驱动器读取），(4) 在启动时预留绿色VM所需的内存空间，使我们能够使用更快的ACPI S3睡眠状态转换，而不是S4状态[15]，(5) 配置绿色VM以使用基于内存的磁盘；
– 通过以下方式提高绿色虚拟机的可信性：（1）减小其大小（如前所述），（2）在启动时对其完整性进行本地和远程证明，（3）始终切换到其原始状态。

2 威胁模型与目标

我们认为攻击者可以攻破并控制红色虚拟机中的整个软件栈。已被攻破的红色虚拟机中的恶意软件可能会尝试攻击虚拟机监控器和绿色虚拟机。拒绝服务（DoS）攻击不在本解决方案的考虑范围之内。攻击者无法访问用户的物理系统。

我们认为所有芯片组硬件和I/O设备都是可信的。我们的可信计算基（TCB）还包括虚拟机监控器以及绿色虚拟机中的软件栈。后者通常较大，但我们将其最小化，并应用使用限制和安全保护机制。如果受保护的用户应用程序访问远程服务，我们也认为该远程服务是可信的。客户端用户应用程序与远程服务器之间的通信通道的隐私和安全通过加密方法实现。

我们的解决方案假设受保护的用户系统上存在硬件虚拟化支持（例如英特尔VT-x），包括SLAT和IOMMU扩展（例如Intel EPT和VT-d），以及支持可信环境的平台级增强功能（例如TPM和Intel TXT）。

3 “替代红-绿虚拟机”保护方法

我们的HV交替调度这两个虚拟机，同一时刻只有一个虚拟机运行，另一个则处于暂停状态。当在运行中的虚拟机中透明地生成一个专用的ACPI睡眠事件并被HV截获时，就会触发从当前运行的虚拟机切换到被暂停的虚拟机。

虚拟机切换机制基于以下假设：每个虚拟机中的ACPI事件由其操作系统处理，该操作系统负责保存完整的机器状态，以便之后能够恢复。虚拟机监控器（HV）唯一需要负责的任务是拦截客户机操作系统在其内部睡眠请求处理结束时发送的ACPI睡眠请求，以关闭CPU。此时，虚拟机监控器可以认为当前虚拟机的状态已由该虚拟机的客户机操作系统根据生成的睡眠请求完全保存。通过介入正常的ACPI睡眠路径，虚拟机监控器避免执行最后一步（即关闭CPU），而是将其转换为一个发送给已挂起（睡眠中）虚拟机的ACPI唤醒信号。自此之后，进行虚拟机切换，即加载并恢复目标虚拟机。

新虚拟机1说明了交替执行策略。某一时刻仅运行一个虚拟机，使得我们的虚拟机监控器能够将当前正在运行的虚拟机直接访问和控制几乎所有的主机硬件资源。该策略极大地减少了虚拟机监控器的规模和复杂性。

虚拟机监控器的主要职责是利用硬件虚拟化支持，隔离并保护其自身和绿色虚拟机所加载的内存区域，防止红色虚拟机的访问。

另一个重要的安全属性是绿色虚拟机I/O通道的可信性。当绿色虚拟机被唤醒时，它会认为所有主机的I/O设备都处于不一致状态，并重新初始化它们。通过这种方式，已攻破的红色虚拟机中的攻击者无法在I/O设备中存储恶意数据，从而试图影响绿色虚拟机状态和行为。

4 增强绿色虚拟机的可信属性

尽管绿色虚拟机在设计上可信，但由于其庞大的软件栈，仍可能被攻破。我们提出了一些技术来降低此类风险。

完整性证明 。一种常见的方法是对用户系统上已启动的软件（例如固件、引导加载程序、虚拟机监控器和绿色虚拟机的软件栈）的状态进行安全测量。该机制称为安全启动，可用于本地和远程证明当前系统状态是可信的。如果绿色虚拟机的镜像已损坏，则不会启动该绿色虚拟机。远程服务也可以要求用户系统证明其完整性，拒绝与无法证明其完整性的客户端通信。

无状态绿色虚拟机 。涉及两种机制：
1. 每当切换到绿色虚拟机时，都应以其原始状态启动。该状态在主机系统启动期间加载到内存中。当用户从绿色虚拟机切换到红色虚拟机时，虚拟机监控器不会保存任何状态信息。因此，用户无法恢复之前的绿色“会话”。尽管这种策略存在可用性限制，但它限制了攻击者在之前会话中获得的对绿色虚拟机的可能控制。
2. 我们的绿色虚拟机配置为使用基于内存的磁盘。通过这种方式，我们消除了两个虚拟机之间因共享硬盘驱动器而产生的干扰。

精简且受限的软件栈 。我们通过以下方式应用了此方法：
1. 准备仅包含一个特定安全敏感型应用的绿色虚拟机。因此，我们的策略要求用户每运行一种不同的安全敏感型应用，就需要使用一个不同的绿色VM的镜像。
2. 将绿色虚拟机的操作系统配置缩减至仅运行该安全敏感型应用所需的最小程度，也可以将其配置为仅包含所需的功能。
3. 限制从绿色虚拟机访问的网址。定制应用（例如互联网浏览器）可以被修改为仅允许访问一个可信网址，即该应用应访问的服务的网址。

运行时保护 。我们使用了U-HIPE[7]，一种基于虚拟化的内省模块，该模块在虚拟机监控器中运行，并保护绿色虚拟机中的客户机操作系统和定制应用。该保护机制对绿色虚拟机的所有内存页施加 W ⊕ X（写入异或执行）权限。最初，所有页面均被标记为只读。当首次访问某个页面时，如果尝试执行，则该页面将永久设置为可执行但不可写；如果尝试写入，则设置为可写但不可执行。

5 缩短切换至绿色虚拟机的切换时间

内存启动 。在主机系统启动时，绿色VM的镜像被加载到内存中（参见图2中其在内存中的位置），并由虚拟机监控器保护为只读。绿色虚拟机从内存启动将更快，唯一需要执行的操作是在绿色虚拟机的保留内存中创建该镜像的可写副本。

基于待机的切换 。可用于交替执行两个虚拟机的ACPI睡眠状态是S3和S4。在这两种状态下，所有设备都将断电并丢失其状态，但S3状态下的内存除外。只要我们的HV在启动时间保留了供两个虚拟机以及绿色VM的镜像使用的内存（见图2），就可以使用更快的ACPI S3转换，因为基于ACPI的切换过程中内存内容不会受到影响。

RAM磁盘使用 。为绿色虚拟机使用基于RAM的硬盘驱动器不仅使其更安全，而且减少了其启动时间，因为只需访问内存。

减少内存需求 。这是为绿色虚拟机定制简化软件栈的逻辑结果：虚拟机镜像越小，其启动时间就越快，因此从红色虚拟机切换到绿色虚拟机的速度也越快。

6 实现技术方面

绿色虚拟机镜像包含一个定制构建的Linux内核，其中嵌入了一个最小化的initramfs，该文件系统包含基于BusyBox的环境、一个X.Org安装实例以及一个Chromium浏览器。该镜像的大小约为 130MB。

在虚拟机监控器启动期间加载绿色虚拟机镜像，并验证其真实性。在可用的情况下，使用硬件支持来实施安全启动过程（例如 Intel TXT）。镜像加载后，创建红色和绿色虚拟机。在此阶段，绿色虚拟机仅被部分初始化。

当红色虚拟机通过“int0 × 15/E820”向BIOS请求内存布局时，该调用会被虚拟机监控器拦截，并修改内存映射，将绿色虚拟机所使用的空间标记为保留。此外，虚拟机监控器通过Intel EPT禁止红色虚拟机访问该区域。

红色虚拟机切换到绿色虚拟机发生在专用的休眠事件上。用户按下按钮后，通过VMCALL通知虚拟机监控器切换到绿色虚拟机，然后使用Windows API启动 ACPI S3状态。虚拟机监控器拦截指示CPU进入S3休眠的I/O事件。此时，所有设备都已被其操作系统驱动程序置于S3休眠状态。系统阻止CPU进入休眠状态，并唤醒绿色虚拟机。

为了向绿色虚拟机提供硬件的“默认”状态，使用ACPI方法为整个PCI层次结构供电。每个PCI配置空间都会恢复到主机启动期间或调用Windows API S3睡眠请求之前所记录的快照内容。可能需要针对特定硬件情况进行微调，但若在虚拟机监控器内嵌入所有可能的网络和视频卡驱动程序以正确初始化每个设备，则是不可行的，并且会显著增加可信计算基大小。

绿色虚拟机的内存映射通过EPT进行配置，以允许访问启动时为其保留的地址范围以及设备用于MMIO的内存范围。其接收的RAM地址范围通过重映射被压缩到 1MB地址之上的连续空间，并同样通过VT-d进行重映射。

Linux内核启动并运行BusyBox作为“init”进程后，启动X.Org环境，然后启动Chromium浏览器，并将自定义网站设置为主页。已配置特殊的 iptables规则，严格限制网络访问仅满足安全应用的需求。

用户在绿色虚拟机内完成安全操作后，会使用另一个ACPI睡眠事件将控制权恢复到红色虚拟机。

7 性能测量

我们的宿主系统是配备英特尔i7@3.4 GHz处理器、 4 GB DDR3内存和 500 GB硬盘驱动器的戴尔Optiplex 990。红色虚拟机运行Windows 7/x64，其内存分配为宿主系统的内存减去虚拟机监控器、绿色VM的镜像以及正在运行的绿色虚拟机所需的内存，即约2.5 GB。绿色虚拟机分配了 1 GB内存，并配置为使用基于初始RAM文件系统的 RAM磁盘。它运行Linux 3.8.8，并在其上构建了一个由BusyBox 1.23、X.Org X11R7.6包和Chromium 31.0组成的最小用户空间环境。我们使用了专有虚拟化层。

我们估算了绿色虚拟机所需的最小空间，得到的压缩后（LZO）镜像大小约为 138 MB，来自未压缩的 8 MB Linux内核、 81 MB X.Org和 225 MB Chromium。表1的第一列展示了基于不同压缩方法的虚拟机镜像的不同大小。运行此类发行版所需的最小内存约为 1 GB。

我们测量了由HV功能引起的开销。它包含两个部分：（1）启动时间，用于加载HV和绿色虚拟机。作为一个一次性操作，其开销会随着系统运行时间的延长而减弱。该开销取决于HV和绿色VM的镜像大小以及启动设备的读取带宽。在我们的测试中，我们通过 1 GB网络链接从PX启动，对于给定的大小大约需要 2 s。（2）保护开销，由HV运行所施加。我们的HV实际上不引入任何开销，因为它仅拦截极少数事件：“int 0× 15”和ACPI S3睡眠。这两个事件分别仅在特定情况下产生，即虚拟机的启动时间和用户的切换请求。除此之外，HV的开销仅来自虚拟化硬件本身，这部分开销与我们可优化的部分无关。

测量红色虚拟机到绿色虚拟机的切换时间时，我们考虑了涉及的主要三个步骤：(1) 红色虚拟机的Windows休眠（对休眠请求的内部处理），(2) 虚拟机监控器对ACPI S3的拦截以及准备唤醒绿色虚拟机，以及 (3) 绿色虚拟机 Linux的唤醒。表2列出了测量时间的平均值。总的切换时间平均约为 18 s ，与Lockdown相比大约减少了2倍[15]。

我们测量了在不同镜像下 Linux 启动时间在裸机硬件上的表现。表1展示了结果。最后一行的总时间与表2第3列时间之间的约 2s差异是由于I/O设备准备导致的虚拟机管理程序的开销，以便一致地唤醒绿色虚拟机。

8 相关工作

与我们的方案最相似的是Lockdown [15]。主要区别在于我们所采用的方法，这些方法用于提高绿色虚拟机的可信度并减少红绿虚拟机切换时间。

SecureSwitch [13] 也使用了类似的策略，但他们没有使用虚拟化来隔离两个环境，而是使用 BIOS 和 SMM。尽管他们的方法速度更快且基于更小的可信计算基(TCB)，但相比我们的方法，其灵活性和通用性较低。

其他低级别的解决方案，如Oasis[12], HyperCheck [16]，即使由于采用更低层级的硬件机制而实现了更小的可信计算基(TCB)，但在所提供的可信（绿色）环境方面仍存在局限，或依赖于定制硬件。实际上，新一代处理器 [5]将包含专用的硬件支持（例如英特尔SGX），以隔离应用程序（飞地）中不受信任的应用程序部分和环境，从而自然地提供更小的可信计算基(TCB)。

与我们的策略相比，它们的主要问题在于，仅靠隔离不足以运行需要与不可信环境协作的实际应用程序。

在此背景下，其他解决方案如Flicker [10]、Wimpy-kernel [17]、Over-shadow [1]、VirtualGhost [2]提出了隔离的飞地与不可信操作系统之间可信通信的方法。然而，目前尚无通用方法来验证此类通信。尽管我们的方案相对较重，但它支持运行功能复杂的应用程序，并且自然地在用户与这些应用程序之间提供可信I/O通道。

9 结论

我们提出了一种为用户提供可信环境以运行其应用程序的方法。该方法通过交替运行两个虚拟机来实现：红色（不可信）和绿色（可信）。我们开发了多种方法，以提高绿色虚拟机的可信性以及红绿虚拟机切换时间。

替代红绿虚拟机保护方法存在一些局限性，我们希望在不久的将来解决这些问题。其中一个问题是该方法的可用性由于切换时间仍然相对较长以及使用限制，影响了其可用性。其他问题涉及如何说服用户在运行安全敏感应用时切换到绿色虚拟机，让用户清楚自己正在交互的虚拟机，以及如何直观地验证绿色虚拟机的真实性等。