@dyk
2015-07-12T13:48:01.000000Z
字数 3513
阅读 362
ReadingNote
DSN-W 2012
最近关于如何防止虚拟机被恶意的hypervisor的攻击越来越受关注。但是很多解决这方面问题的先前工作都容易被rollback攻击。由于很难分辨正常的suspend/resume操作，迁移操作与回滚攻击。有一些先前的系统只是简单的禁止虚拟机的回滚，而另外一些则需要用户的过度参与。作者在这篇文章中提出了新的思想来解决这个问题。在一个小的TCB中记录所有的suspend/resume操作以及迁移操作的日志，用户通过对这个日志进行审计来检查恶意的回滚的同时限制Hypervisor对该虚拟机的操作
文章提出的解决方案需要有一个end user能够判断这个rollback是否是恶意的。所以作者将所有的回滚的时间的日志都安全的记录起来。通过审计用户能够检测可以的回滚并且向云管理员提供这些操作的必要性。或者更加高级的定义回滚的策略限制云管理进行操作。这个解决方案仍然需要很少的用户参与。
CloudVisor: 采用nested VMM技术来隔离hypervisor与用户虚拟机。这个小的hypervisor通过监视hypervisor与虚拟机之间的控制流检查是否是合法的操作，保护了用户虚拟机的隐私性和完整性。控制EPT（extended page table）隔离他们的内存区域。并且在每次hypervisor访问的时候加密这些页面。并且采用MHT（Merkel Hash Tree）来保护虚拟机磁盘镜像的完整性。
H-SVM: 采用物理硬件中的microcode程序来加强内存的保护。物理硬件将hypervisor要访问的页面全部都加密一遍，并且使用hash tree来保护用户机内存的完整性，hash树的根需要被存放在受保护的内存区域。
HyperWall: 这是另外一个相关的工作。它通过扩展物理硬件来支持细粒度的控制访问存储。每一个虚拟机需要明确自己的隐私页面以供物理硬件保护。
然后CloudVisor，H-SVM都不能防御防御上面提高的回滚攻击（通过回滚暴力破解，跳过安全检查等等）。回滚攻击能够以多种的形式发动，例如hypervisor能resume一个老的snapshot，或者将现有的虚拟机克隆到另外一个机器上面，控制不同的版本。要分辨回滚攻击和正常的回滚是很难的。而HyperWall完全不能做虚拟机的快照，由于hypervisor不能访问用户的内存。并且hypervisor也不能迁移虚拟机，只允许self-migration。HyperWall要求了很多的用户的参，并不实际。
系统要求回滚操作不能在一个Running Epoch中（每个Running Epoch 开始与 VM boot/resume 结束与VM shutdown/suspend）
作者在CloudVisor中添加了4个Hypercall：vmboot，vmshutdown，vmsuspend和vmresume。这些操作控制域并不能跳过。
日志的记录就是在以上这4个hypercall的过程中实现的。每个日志项是一个三元组｛操作，时间戳，快照版本｝时间戳由硬件时钟支持。快照的版本是由磁盘的哈希，内存的哈希，CPU状态的哈希构成的。为了放置log被篡改每一次日志项增加了都向TPM的NVRAM中增加新的度量。由于虚拟机可能被迁移，所以虚拟机的日志也是分布在整个系统当中的。审计的时候需要将所有的log放在一起进行审计。
Reference List
其他的引用都是针对Hypervisor的不安全问题所给出的解决方案。
Details
S&P'11
为了保护计算，一个安全的架构不仅需要保护那个软件，同样需要保护软件的操作时候的状态。如果软件回滚到一个正常但是老旧的版本，那么它很有可能发现错误。所以保护软件的状态不仅仅是保护状态的私密性与完整性。为了达到上上面说的目标，作者提出了Memoir，Memoir是第一能够保证软件模块状态的连续性的系统。换句话说，Memoir保护软件的状态保持持续并且不会被破坏。Memoir的最大贡献是在做到rollback resistance的同时并没有让系统更加的容易发生crash。Memoir实现了一个确定的模块，这个模块精确的将被保护模块的请求记录的总结存放在NVRAM里面。并且在发生crash的时候仅仅允许安全的命令重新执行。由于现在的硬件设备的NVRAM并不能频繁的进行读写，作者对这个问题也做出了优化。
Yubin Xia
Yutao Liu
Haibo Chen
Binyu Zang
作者最新的研究方向在于移动安全
DSN-W 2012
由于虚拟化技术的应用，单台机器上面的资源越来越多（一个物理机器上面可以运行多个VM）。然而Hypervisor层面并不是朝着更加可靠的方向发展，而是朝着功能更加全面的方向发展使得Hypervisor层可能由于各种的错误而崩溃。这个单个Hypervisor层面的崩溃很容易使数以百计的虚拟机发生很大的问题。
作者采用TinyChecker技术减轻了这个问题带来的影响。TinyChecker采用nested hypervisor技术使得hypervisor层面的错误对于客户虚拟机是透明的。TinyChecker的代码量很小，有着透明的错误检测与恢复功能。TinyCheck记录了虚拟机与hypervisor之间的所有的通信，保护VM的隐私数据，检测与恢复hypervisor层面的错误。
HPCA'13
在平台上面租户的数据的安全依赖与云的安全架构。然而有与硬件和软件都是有潜在存在窥视心理甚至是恶意的云操作者。现在发生许多的数据泄漏也并不奇怪。先前的解决方案都要求能够对云平台本身做出修改并且不能够应对控制物理硬件的攻击者。作者解决的问题是如何在硬件与软件都被攻击者控制的情况下面如何透明的保护客户虚拟机。作者提出了HyperCoffer，HyperCoffer是一个软件硬件的解决框架。
HPCA'14
虚拟机自省（VMI）常常用来做入侵检测，恶意软件分析，以及内存侦查。之前的解决方案有的是停止虚拟机进行VMI以保持dump的内存和虚拟机的当前内存是一致的，有些方案并不保证dump的内存和当前的内存状态是一致的。作者提出了TxIntro，通过改进hardware transactional memory（HTM）来同步内存做到内存一致的内存自省。
这几个作者的文章都是基于hypervisor层面的不安全问题来解决用户的数据安全，基本上面采取的都是nested hypervisor的解决方案。
回滚也能用来欺骗VMI？