本周精读的是分布式顶会Middleware'18的一篇paper。
下面按照paper的结构逐一介绍分析：（主要是模型的设计部分）
abstract
目前的云基础设施几乎没有帮助保护用户免受攻击的方法，而本文提出的CRIMES就是一个基于证据的、模块化的云平台安全框架，使用投机执行和内存内省工具实现实时检测恶意行为。通过缓冲VM输出(即在扫描完成之前，CRIMES会对攻击造成的破坏程度提供强有力的保证，同时将开销降至最低。当检测到攻击时，CRIMES会回滚到最近的一个检查点，并执行自动法医分析，以帮助查明攻击的来源。
用于提高云中虚拟机的安全性。
Speculative execution （投机执行，又称预测执行）：一个用于执行未明指令流的区域。当分支指令发出之后，传统处理器在未收到正确的反馈信息之前，是不能做任何工作的，而具有预测执行能力的新型处理器，可以估计即将执行的指令，采用预先计算的方法来加快整个处理过程。
INTRODUCTION
paper's background：
Cloud applications are storing ever increasing volumes of data— data that is often of high value to attackers who wish to steal company secrets or personal information. Unfortunately, current cloud platforms are better prepared to offer performance management services than they are to offer security. This leaves the onus on customers to ensure the integrity of their applications.
Security remains a challenging problem for applications and operating systems. On one extreme are approaches such as virus scanners that periodically scan a system to detect evidence of attacks; this incurs relatively low overhead, but can leave a system vulnerable for long periods of times between scans. At the other end of the spectrum are memory safety tools such as Address Sanitizer [32], Safecode [14], or Intel MPX [26] which use runtimes, compilers, or specialized hardware to instrument memory accesses and detect attacks such as bu!er over"ows as soon as they occur. Such systems can add high cost, and only focus on a limited set of attacks within a single application. A further challenge is not only detecting attacks, but precisely pinpointing the root cause in order to prevent such an attack from happening again in the future.
paper's contributions:
• A framework for online detection of attacks in VMs by leveraging memory introspection tools.
• VM checkpointing optimizations to support efficient speculative execution between security scans.
• Post-attack analysis methods that automate forensic analysis or give precise visibility at the point of an attack.
SECURITY AS A CLOUD SERVICE
Current tools that detect and prevent attacks are typically deployed by customers inside their VMs, e.g., virus scanners or memory safety compilers or runtimes. Instead, we make the case for placing security tools in the virtualization layer as a service offered by the cloud provider.
A key concern in providing security is the window of vulnerability.
In CRIMES, we seek to provide the best of both worlds by performing multiple scans per second and using output buffering to provide external users the same guarantee as a zero window of vulnerability approach.
Threat Model
这部分概述了CRIMES所采取和防范的威胁模型。我们的重点是提供一个有效的框架来实时分析vm，因此我们假设攻击会在内存中留下证据，这些证据可以被我们的扫描器检测到。有一些众所周知的技术可以用来寻找CRIMES可以利用的许多攻击的证据,例如,发现缓冲区溢出通过检查canaries(8,22),内核结构比较好的状态检测攻击系统调用表劫持[11],或解析内核数据结构发现异常行为如非法进程[18]。我们假设攻击会在内存中留下证据，并在VM中提供支持以确保发生这种情况(例如，在堆中设置canaries)。我们假设攻击者无法删除他们在扫描间隔内留下的证据，通常扫描间隔为几十毫秒。我们认为这是一个合理的假设，因为尽管攻击可能利用系统来获得更高的特权，但它通常不能重建攻击前的内存。例如，像堆“canaries”这样的特殊位可以由攻击者控制之外的随机数生成器创建，并插入内存中的对象周围——如果它们被缓冲区溢出之类的攻击意外覆盖，系统可以检测canaries是否正确。最后，我们假设攻击可以影响VM中的应用程序和/或操作系统，但它不能影响VM边界之外的系统
DESIGN
原型是作为Xen管理程序的一部分实现的， 并为运行在管理程序上的vm提供了三个关键特性。首先，Checkpointer推测性地为每个predetermined epoch执行VM，暂停执行并在每个predetermined epoch结束时获取一个VM的检查点。其次，当VM处于暂停状态时，检测器会对VM和任何攻击痕迹进行全面的安全审计。第三，在找到这样的证据后，它停止VM的执行，分析器开始攻击后分析阶段，进行彻底的法医检查。
Speculative Execution
图2显示了带有CRIMES的VM执行的时间轴。执行被划分为几个epochs。在每个epochs期间，VM都是推测性地执行的，即， VM正常运行，但所有外部输出(如磁盘写或网络数据包)都已缓存。缓冲将VM的所有外部输出在epoch期间保存在管理程序中。在每个epoch结束时，VM被挂起，它的完整性由彻底的安全审计决定，创建一个检查点，并释放缓冲区。
缓冲VM的输出可以确保在epochs期间发生攻击时，效果不会传播到VM之外。这确保最终用户不会受到这种攻击的影响。如果epoch结束时的安全扫描成功，则释放缓冲区，提交投机执行期间的结果。然后推测VM将在下一个epoch中执行，并且循环将继续。
在VM安全审计失败的情况下，CRIMES试图提供自动分析，以帮助确定攻击的原因，甚至逆转攻击。为此，每次扫描成功后都会创建VM状态的检查点(例如CPU寄存器、内存和磁盘)，以提供一个可以安全回滚的点。然后，如果怀疑故障是由暂时故障引起的，可以重播VM，或者对攻击的根本原因进行深入的法医分析。
在我们当前的实现中，CRIMES主要关注检查点CPU和内存状态，但这很容易扩展到包括磁盘快照[13]。创建检查点需要暂停VM，因此这一过程是CRIMES中最大开销的来源——在4.1节中，我们介绍了几种降低成本的优化方法。我们目前的实现只维护最近的检查点，然而，犯罪可以扩展到包括检查点的历史，这将有助于法医分析。每个检查点epoch的间隔是一个可调参数，它取决于在VM上运行的应用程序和VM所需的安全级别。每个epoch的范围从几十毫秒到几百毫秒不等。
较低的间隔导致更频繁的审计，这减少了输出缓冲的影响，但是会增加检查点开销。例如，承载web服务器的VM需要快速响应时间(低延迟)，但是由于网络包是缓冲的，VM的响应时间可以由epoch间隔和完成安全审计所需的时间之和来延长。在这种情况下，延迟敏感VM的epoch间隔可以低至10-20ms。对于不依赖于网络或磁盘延迟的vm，例如CPU绑定工作负载，可以将epoch间隔设置得更高，例如200ms，以减少检查点开销。
上述输出缓冲可以提供具有零漏洞窗口的保护，因此我们将这种模式称为同步安全，如[9]所示。然而，并不是所有的vm都需要如此强大的保证。通过禁用缓冲，CRIMES可以提供最佳的安全性，攻击仍然可以快速检测到，但是它们可能会导致一些外部输出在检测之前离开系统。然而，由于许多当前的系统有几分钟甚至几天的漏洞窗口，最好的保护可能仍然是可取的，因为它可以获得更高的性能，但只有毫秒级的漏洞周期。
Detection
确定VM是否安全需要在每个epoch结束时对VM进行健壮而全面的审计。本节描述CRIMES如何有效地检测和查明VM中运行的内存错误和恶意软件的范围。要从管理程序解释VM的内部，我们需要有关其符号名称和相应内存地址的信息。虚拟机内省(VMI)技术使这成为可能，例如通过使用一个系统。映射文件，用于定位运行已知Linux[16]版本的VM的内核数据结构。
VMI主要用于VMs上的离线内存取证分析。VMI技术帮助取证人员从VM外部查看和分析关键用户级和内核对象、符号和其他关键组件。这允许在任何给定时间点对VM内发生的事情进行健壮的分析。
CRIMES可以在VM上执行自省，也可以不借助VM。CRIMES的Detector组件为不同的基于vmi的安全扫描提供了一个模块化的框架。在每个epoch结束时，Checkpointer组件向检测器发送消息，以触发扫描。
为了降低在每个epoch结束时执行审计的成本，Checkpointer为检测器提供了一个dirtied pages列表。这允许安全审计只关注已修改的页面，因此可能包含攻击的证据。检测器将触发一个或多个扫描模块，这些模块可以根据VM可能面临的攻击类型以及VM是否知道扫描系统进行定制。我们工作的主要目标是提供一个框架，根据VM运行的任务的性质，可以将此类模块添加到该框架中，以检查VM中不同类型的安全问题。此外，我们的重点是保持扫描的开销最小(在几毫秒内)。
Response
在Detector模块识别出潜在的攻击(内存错误或恶意软件)之后，CRIMES的Analyzer程序将被激活，生成一份全面的安全报告，以帮助管理员在未来减轻这种形式的攻击。在生成此报告之前，CRIMES可以选择性地执行额外的取证，以确定攻击开始时的系统状态。一旦检测到攻击，CRIMES将暂停VM以防止破坏。
Analyzer的response可以被分为以下两个阶段：
Rollback and Replay (optional)
Postmortem Analysis
IMPLEMENTATION
CRIMES’s implementation leverages Xen’s Remus high availability system [13] for checkpointing, and LibVMI [27] and Volatility [4] for memory analysis and forensics.
EVALUATION
To evaluate CRIMES, we demonstrate how performance optimizations to Remus foster a speculative execution environment with which our modular security scans can run with little overhead. Our experiments are run on HP ProLiant GL160 G6 servers with two Intel Xeon X5650 CPUs @ 2.67 GHz and 16 GB of RAM that run Xen 4.7 with an Ubuntu 14.04, Linux kernel 3.7, Domain-0. Our VMs run OpenSUSE 13.1 with Linux kernel 4.8 running GCC version 4.8.1
We use PARSEC [7] version 3.0 for our evaluation, a common CPU and memory intensive benchmark suite. We run PARSEC benchmark with the memory safety tool AddressSanitzer [32] by compiling it with -fsanitize=address "ag. For network workloads we chose to use wrk, a HTTP benchmarking tool [17] as the workload generator with NGINX version 1.11.4 as our web server.