• A Survey on Hypervisor-Based Monitoring
  • 1. introduction
  • 2. BACKGROUND
    • 2.2. Out-of-VM–Based Monitoring
  • 3. THE SEMANTIC GAP PROBLEM
    • 3.1. What We Observe
    • 3.2. What We Want
  • 4. APPROACHES

A Survey on Hypervisor-Based Monitoring

计算机监控系统的一个目标始终是：对监控对象全面查看，同时隐蔽地保护监视器本身。

实现方式：基于虚拟机管理程序，或基于虚拟机的监控。

挑战：语义鸿沟。

1. introduction

计算机系统监控是维护系统安全的基本机制。入侵检测，访问控制（例如，DAC，MAC和RBAC），沙盒，内联参考监视器，防火墙和防病毒都涉及安全监视。理想的监控系统应该既具有受监控目标的完整视图，又能够（隐蔽地）保护监控系统本身。虽然有很多方法可以做到这一点，但这不是一项简单的任务。在过去的几十年中，已经进行了大量研究以寻找更好和更安全的方法来开发这种监视器。

到目前为止，一种有希望实现对其所观察系统的监视器的宏观视图和强有力保护的策略是利用计算机系统设计为具有层的分层结构[Dijkstra 1968]的事实。

传统上，从上到下，有应用层，操作系统（OS）层和硬件层。通常，每个层实现其上方层的抽象和接口，并使用底层的预定义接口来执行其自己的功能。每层都与它上面的层完全隔离，层越低，它对系统的控制越多，但抽象越少。

作为在硬件和OS层之间运行的层，管理程序最早是在20世纪60年代提出的[Popek和Goldberg 1974]。 虚拟机管理程序 - 也称为虚拟机监视器（VMM） - 使计算环境能够在单个物理计算机中同时运行多个独立的操作系统，从而更有效地利用可用的计算能力，存储空间和网络带宽。 将虚拟机管理程序层引入我们的计算堆栈的根本原因是单个服务器中的容量非常大，以至于大多数工作负载几乎不可能有效地使用它。 因此，虚拟化成为提高资源利用率的最佳方式，同时还简化和自动化计算单元管理。 尽管这种计算模型最初设计用于逻辑上为大型机中不同应用程序的时间共享提供资源，但它现在支撑着当今的云计算和数据中心。

除了将我们的计算范例从多任务处理推向多操作系统之外，管理员还将系统监控从传统的虚拟机内（VM）监控推向了基于虚拟机管理程序的虚拟机监控。这是因为客户操作系统在VMM提供的虚拟资源上运行[Barham et a，2003l） ，为灵活性和控制提供了新的机会，因为VMM本质上是一个软件层，软件更容易修改，迁移和监控。通过在VMM层提取和重建客户操作系统状态，可以实现虚拟机外监控，使监控系统能够从外部控制，隔离，插入，检查，安全和管理虚拟机[Chen and Noble 2001]。 Garfinkel和Rosenblum [2003]关于此主题的开创性论文，介绍了第一个基于管理程序的监控系统，“调用[ed]这种从外部检查虚拟机的方法，目的是分析虚拟机内部运行的软件。 virtual machine introspection （VMI）。“在本文中，我们将使用更通用的术语”VM外部“来指代基于管理程序的监视，包括VMI。

但是，由于位于客户操作系统下方的一层，因此所有VM外解决方案都必须解决语义差距问题。 具体来说，存在语义差距，因为在管理程序层，我们只能访问VM的硬件级状态的原始数据 - 即其CPU寄存器和物理内存，尽管我们也可以访问指令级执行状态 管理程序的类型（例如，基于二进制翻译的VM）。 但是，我们想要的是有关客户操作系统状态的语义信息，例如正在访问的变量，变量类型和客户操作系统内核事件。 因此，我们必须桥接语义鸿沟以获得有意义的客户OS状态信息。 在过去的十年中，已经有许多提出的解决该问题的方法，在不同的约束条件下运行，并且从纯手动到全自动化。

虚拟机外监视器与传统的虚拟机内监视器相比具有许多优势，因为它们运行在更高的权限级别，并且与它们监视的客户操作系统中的攻击隔离，并且还因为它们位于客户操作系统之下一层，并且可以插入所有监视器客户OS活动。因此，虚拟机外监视器已被广泛用于许多安全应用程序，从只读内省（例如，Garfinkel和Rosenblum [2003]）到可写重新配置和修复（例如，Fu和Lin [2013b]和Lin [ 2013]），被动入侵检测（例如，Joshi等人[2005]）主动预防（例如，Payne等人[2008]），防御恶意应用（例如，Dinaburg等人[2008]和Srinivasan等） al。[2011]）来防御恶意操作系统（例如[Chen et al.2008]），恶意软件分析（例如，Lanzi等人[2009]和Yin等人[2007]）来记忆取证（例如， Dolan-Gavitt等人[2011b]和Hay和Nance [2008]），等等。

鉴于在虚拟机外监测方面进行了大量研究，迫切需要将该领域的知识系统化。因此，在本文中，我们希望遵循技术足迹并跟踪虚拟机外监控的演变，重新审视已完成的工作，讨论我们的位置，并阐明应该去哪里。我们首先讨论为什么我们需要VM外监控并讨论第2节中的技术背景。然后我们将描述第3节中所有VM外监控所面临的语义鸿沟挑战。接下来，我们总结了这个挑战是如何进行的。在第4节中的不同约束条件下解决，并在第5节中对VM外监控的所有应用程序进行了分类，以及如何在第6节中对它们进行了部署。我们讨论了剩余的研究问题以及虚拟机外监控的未来趋势在第7节中，然后在第8节中进行相关的工作审查。最后，我们在第9节中作出结论。

2. BACKGROUND

在本节中，我们将讨论为什么需要进行VM外监控的动机。 我们首先回顾一下VM监控，并在2.1节中讨论它的优缺点。 然后，我们将介绍虚拟机外监控，并在第2.2节中讨论其优缺点。 最后，我们将在2.3节讨论这项工作的范围。

2.2. Out-of-VM–Based Monitoring

类型2（hosted）虚拟机管理程序，在传统操作系统中运行。 换句话说，托管管理程序在主机OS顶部添加了不同的软件层，并且客户OS成为硬件上方的第三软件层。 众所周知的这种类型的虚拟机管理程序示例包括KVM，VMware Workstation，VirtualBox和QEMU。

3. THE SEMANTIC GAP PROBLEM

VM系统的主要优点是可以直接访问各种OS级抽象。 但是，在使用虚拟机管理程序时，会丢失对操作系统内所有丰富语义抽象的访问权限。 虽然虚拟机管理程序可以全面了解它们监视的虚拟机状态，但不幸的是，这个宏观视图只包含没有上下文的1和0。 因此，我们可以观察到的内容（第3.1节）和我们想要的内容（第3.2节）之间存在语义上的差异，如图1所示，我们必须将其桥接以提供有效的监控服务。 在本节中，我们将更详细地介绍语义差距问题。

3.1. What We Observe

除了本机管理程序观察到的快照视图之外，仿真管理程序还可以具有guest虚拟机操作系统执行的连续视图。 特别是，他们可以观察到以下内容：

• 程序计数器：他们可以知道执行哪些指令及其拆卸代码。
• 指令操作码和操作数：对于每个执行的指令，它们可以观察其操作码和操作数。
• 控制流传输：可以观察所有控制流传输（例如，call / jmp / ret，条件分支）及其源和目标地址（如果适用）。
• Call堆栈：如果存在堆栈帧指针，则可以遍历堆栈，或者可以透明地检测指令以构建调用堆栈信息。
• Context-switch：还可以观察每个特定进程或线程执行上下文。

3.2. What We Want

鉴于虚拟机管理程序只能访问低级二进制数据，我们必须将数据转换为更高级别的抽象，以提供有用的监视服务。 通常，这些抽象可以分为两种类型：数据状态抽象和控制状态抽象。

数据状态抽象。 数据状态包括当前内核对象的状态或受监视进程内的对象（基本上是内存状态）以及当前CPU执行状态。 更具体地说，我们对以下内容感兴趣：

• 变量，对象和虚拟地址空间：给定客户操作系统的物理内存，我们想知道内核或受监视的过程变量（或对象）的位置，变量或对象的虚拟地址，以及如何在物理内存中定位虚拟地址。

• 数据结构类型及其连接：我们还想知道对象类型，数据结构及它们的指向关系（这样我们就可以遍历它们并验证它们的完整性）。
• 文件系统和文件：给定磁盘映像，我们感兴趣的是正在使用的文件系统类型以及文件所在的位置。
• 中断，异常和其他内核事件：对于观察到的硬件事件，我们希望获得有关它的其他详细信息;对于中断或异常，我们想知道它是哪个特定的中断或异常。此外，如果可能，我们希望识别其他内核事件，例如何时创建或销毁某个内核对象。
• Packets和buffers：从观察到的I / O数据中，我们想区分网络数据包和DMA缓冲区。更进一步，我们希望尽可能确定数据包的内容和上下文。

控制状态抽象。数据状态提供运行VM的快照视图，而其粒度取决于虚拟机管理程序控制的时间和频率。在本机虚拟机管理程序中，虚拟机管理程序只有在发生某些硬件事件时才能重新获得控制权，而对于仿真虚拟机管理程序，我们可以在任意时间（取决于我们的兴趣）进行控制。如3.1节所述，尽管可能，使用本机虚拟机管理程序获取连续视图对于大多数应用程序来说效率太低。因此，我们主要关注用于控制状态抽象的仿真管理程序。更具体地说，从细粒度到粗粒度，我们对以下内容感兴趣：

• 指令，控制路径和调用堆栈：知道VM正在执行哪条指令，它所属的控制路径以及调用上下文可以帮助虚拟机外监视器精确地了解客户操作系统的当前状态。通常可以通过仿真管理程序或单步本机管理程序来观察这些细粒度控制状态。
• 函数调用，系统调用，库调用和挂钩：由于指令级监视通常会显着降低VM执行速度，我们可能会以粗粒度的粒度（例如，在函数调用执行级别或某些系统中）进行监视调用，库调用或监视器兴趣钩子）。
• Processes，线程和执行上下文：当存在上下文切换时，我们想知道哪个进程（线程）被切换（从）到，因为控制流通常是线程特定的。对于给定的执行指令，我们还想知道哪个进程或线程正在执行该指令，无论执行是在用户空间还是内核空间。

4. APPROACHES

在本节中，我们总结了为弥合语义鸿沟而提出的一般方法，以及这些方法所针对的具体应用。总的来说，我们分析了2003年至2014年期间从几个高度选择性的安全和系统场所发表的64篇论文（项目）.2请注意，我们的目的并不是要详尽地检查所有论文，因为发表的论文太多了。在其他场地。图2显示了每年在VM外监控主题上发布的论文数量的分布情况。

总的来说，有五种主要方法来弥合语义差距：手动方法（第4.1节），调试器辅助方法（第4.2节），编译器辅助方法（第4.3节），二元分析辅助方法（第4.4节） ）和客户机辅助方法（第4.5节），如图1所示，并在表II中报告。前四种方法基于实施者在构建虚拟机外监视器时面临的约束进行分类。在较高级别，这些约束基于是否存在访客OS数据结构，调试信息，源代码或二进制代码的访问权限。此外，还可以选择完全避免语义差距，但可能会牺牲VMI的安全优势。这种方法，即客户辅助方法，修改客户操作系统内核或将程序放入其中以将信息传递给VM外监视器。

所有这些方法的难度（开发人员实施时）和实用性各不相同。例如，虽然某些手动方法利用有关特定操作系统的详细信息，但它们可能更容易实现。不同的方法在自动化程度方面也各不相同。根据定义，手动方法几乎不涉及自动化，而其他方法可能会以弥合差距的方式使用不同数量的自动化，以及将实施方式从一个移植到另一个的方式。在以下部分中，我们将更详细地研究每种方法，我们将在4.6节中对它们进行比较。