基于轻量操作系统的虚拟机内省与内存安全监测

摘要：针对在传统特权虚拟机中利用虚拟机内省实时监测其他虚拟机内存安全的方法不利于安全模块与系统其他部分的隔离，且会拖慢虚拟平台的整体性能的问题，提出基于轻量操作系统实现虚拟机内省的安全架构，并提出基于内存完整性度量的内存安全监测方案。通过在轻量客户机中实现内存实时检测与度量，减小了安全模块的可攻击面，降低了对虚拟平台整体性能的影响。通过无干涉的内存度量和自定义的虚拟平台授权策略增强了安全模块的隔离性。基于Xen中的小型操作系统MiniOS实现了虚拟机内省与内存检测系统原型，评估表明该方案比在特权虚拟机中实现的同等功能减少了92%以上的性能损耗，有效提高了虚拟机内省与实时度量的效率。

关键词：虚拟机内省；Xen MiniOS；内存监控；完整性度量；入侵检测

中图分类号： TP309.5 文献标志码：A

英文摘要

Abstract：The method of utilizing Virtual Machine Introspection （VMI） in a traditional privileged Virtual Machine （VM） to monitor the memory security of other VMs may weaken the isolation between the security module and other parts of the system， and slows down the total performance of the virtualization platform. In order to mitigate these disadvantages， a security architecture based on implementing VMI in a lightweight operating system was proposed， along with a security checking scheme based on memory integrity measurements. By monitoring and checking other VMs runtime memory in a lightweight VM， the attack surface as well as the performance overhead was reduced. By nonintrusive checking and personalized authentication policy of the virtualization platform， the isolation of the security module was strengthened. A prototype system of VMI and memory detection was implemented based on MiniOS of Xen. Compared with achieving the same function in privileged VM， the proposed scheme can reduce performance loss by more than 92% . It is proved that the proposed scheme can significantly improve the performance of VMI and realtime checking.

英文关键词

Key words：Virtual Machine Introspection （VMI）；Xen Mini Operating System （Xen MiniOS）； 先，虽然Mini-OS的愿意的确是Mini Operating System，但在Xen背景下，Mini-OS已经是一个专用名词，而很少有学者称为Xen Mini Operating System。

其次，就算要写全称，应为Xen Mini Operating System，而不是Xen Mini-Operating System。

memory monitoring； integrity checking； intrusion detection

0 引言

虚拟化技术是云平台能同时为多个用户提供服务的核心技术。在虚拟化技术下，同一物理设备可以被虚拟成多台虚拟设备，由多个用户分别使用且互不影响，从而降低计算成本。然而，虚拟化平台下的安全问题面临诸多挑战[1-2]：首先，传统计算环境下的漏洞攻击在虚拟机（Virtual Machine，VM）环境下同样有效，如Web漏洞CVE20120392、安全外壳协议（Secure SHell，SSH）漏洞CVE20104478、域名系统（Domain Name System，DNS）漏洞CVE20080122等；其次，虚拟化技术使得攻击者有了新的攻击方式，如VMware Tools中的函数库访问漏洞CVE20101141等。

在虚拟环境下，传统的运行在操作系统内部的安全监测程序已不能满足虚拟化环境的安全需求。而在特定的虚拟机中利用虚拟机内省技术实时监测其他虚拟机的内存[3-5]，成为虚拟环境下安全防护的研究热点。例如LibVMI[4]和RTKDSM[5]可以在Xen的Domain0中对Xen平台上其他VM执行监控。HyperCoffer[6]利用了现有的处理器硬件虚拟化扩展技术，在Hypervisor不可信的情况下对虚拟机进行加密与完整性保护。但这些研究均是在虚拟平台的特权虚拟机中实现虚拟机内省，该方法仍存在如下问题：1）特权虚拟机上运行Linux等商业化操作系统，其功能复杂，可信计算基（Trusted Computing Base，TCB）较大，不利于安全模块与其他模块的隔离，增加了安全模块的可攻击面；2）同时，特权虚拟机运行时消耗资源较多，在其中执行内省会拖慢虚拟平台的整体性能。取证虚拟机（Forensics Virtual Machine，FVM）[7-8]利用Xen中的轻量虚拟机MiniOSminiOS与MiniOS含义相同，是否应统一。两者是同一个意思，可以统一称为Mini-OS

建立了多个专用的虚拟机监控器，每一个监控器负责搜索特定的恶意行为特征。但其多个FVM带来的性能损耗较大，其实验原型中也只有对目标系统进程字节级别的访问实验，不能说明大范围内存访问的性能。

为克服上述弊端，本文提出在一个安全隔离的轻量虚拟机中监测其他普通虚拟机内存的安全架构，并用于实时度量系统内存的完整性。主要贡献有：1）提出基于轻量操作系统的安全隔离与监控架构，允许在一个隔离的轻量虚拟机中监测其他客户虚拟机的内存。2）提出基于内存完整性度量的安全监测方案，并将虚拟机内省技术应用到Xen平台的MiniOS操作系统中，实现了系统原型。3）评估原型系统性能，结果表明该机制在多达500页内存的连续访问中可减少92%以上的性能损耗，提高了虚拟机内省与实时度量的效率。

1 威胁模型

1.1 虚拟机内省

虚拟机内省技术允许一个虚拟机监控其他虚拟机的运行状态。一个拥有特殊权限的虚拟机可以通过虚拟机内省访问另一个客户虚拟机的内存，进而从中抽取出运行信息，实时监控该虚拟机状态。虚拟机内省无需改动目标虚拟机系统，可以较好地隐藏自己的监控行为。

开源的虚拟机内省工具有XenAccess、LibVMI、Volatility等。LibVMI[4]源于XenAccess[3]，是在Xen中实现虚拟机内省的库函数包，为操作系统实现虚拟机内省提供函数库支持。Volatility是计算机取证应用较广的开源工具，能为用户提供更为丰富易用的功能。本文借鉴LibVMI的工作，从虚拟平台底层开始，在微小操作系统中实现虚拟机内省技术。

本文实现虚拟机内省的轻量虚拟机称为安全；其他的虚拟机作为监控对象，称为目标虚拟机。安全可以通过虚拟机内省技术，实时读取目标虚拟机的内存，进而分析目标虚拟机的运行状态。

1.2 威胁模型

保障系统的完整性是系统防护的基本目标。完整性要求信息与程序仅以特定的、已获得授权的范围内变化[9]。成功的攻击行为会引起系统部分运行状态的异常变化。若系统任一部分的完整性遭到破坏，则整个系统的完整性便被破坏。本文主要关注客户机系统受到的攻击，如：从用户接口发起的操作系统攻击；在一个客户机内的恶意代码注入攻击；篡改攻击；通过代码注入提升权限实现多个恶意客户机之间的联合攻击等。对系统完整性的实时度量，可检测客户机系统中正在发生的攻击。

威胁模型基于虚拟化平台中的如下假设：1） 假设虚拟机监控器是安全的，攻击者不能利用虚拟机监控器中的漏洞控制整个虚拟机平台。2） 假设启动过程是安全的，包括监控器的启动、虚拟机的启动以及虚拟机内关键应用的启动都是可信的。该状态作为后续执行实时校验的标准。3） 假设客户虚拟机是不安全的，被攻击者可以利用客户操作系统或者应用程序中的漏洞攻陷客户虚拟机系统，破坏客户虚拟机系统的完整性。

安全运行在被监控的操作系统之外，如果被监控的操作系统被恶意程序控制，安全不会受到侵害，故仍然可信。然而，当安全所在的虚拟机被恶意程序侵染之后，通过内省技术得到的信息则是不可靠的，对此本文不作讨论。

2 系统结构

恶意程序会通过修改它所在的环境的状态来隐藏自己。这些恶意程序在设计之初就致力于绕过系统内部的防护程序。然而，如果从系统的外部实时监控系统内部的状态变化，则这些恶意软件将很难隐藏自己的行为。本文在一个微小操作系统中实现虚拟机内省技术，为运行在其他虚拟机上的商业化操作系统提供完整性度量服务，以减少性能损耗，缩小监控系统的可攻击面。

安全实施监控的整体架构如图1所示。安全中存储着其他虚拟机安全可信状态的度量值。在其他虚拟机运行过程中，安全可以借助虚拟机内省技术，获取内存的状态与变化，实时度量目标内存区域的完整性。比如，度量目标客户机系统关键代码是否被修改等。安全所监控的目标内存区域，以及监控的策略与方法，都配置在安全中。

2.1 设计原则

在系统设计过程中设定如下原则：轻量虚拟机、无干涉度量和虚拟机隔离与最小权限原则。下面讨论这3个原则以及相应的解决方案。

2.1.1 轻量虚拟机

在一个专用的虚拟机中完成单个任务，如果使用现有的商业化操作系统，如Linux或者Windows等，则虚拟机启动和运行需要消耗大量系统资源，而完整性校验的工作仅占损耗的一部分，所以会造成资源的浪费，降低运行效率。而微小操作系统可用较少资源完成相同的任务。此外，微小系统的TCB小，给整个系统带来的TCB增长较小。在其他安全条件都相同的情况下，TCB规模越小，系统的可靠性越高[10]。

本文采取Xen源码树中的微小操作系统MiniOS[11]作为安全的系统环境。MiniOS内核规模小，仅需1MB内存就可以运行，且内核简单，没有内核空间与用户空间的分离，也没有多线程的支持。由此，本文在MiniOS中实现虚拟机内省技术。相对于实现在商业化的操作系统中，这样的实现内部结构简单，且具备精简而够用的对外接口，减小安全的可攻击面，同时节约系统资源。

2.1.2 无干涉度量

无干涉是指不修改目标操作系统的代码与运行状态。威胁模型假设所有被监控的客户虚拟机都是不安全的，因此安全不能依赖于对客户虚拟机的修改，且检测过程要对目标虚拟机以及云平台上的其他虚拟机具有隐秘性。借助虚拟机内省技术，度量过程不需要对目标虚拟机的代码作任何增减，故可实现无干涉度量，隐藏安全的监控行为，增强安全与被监控对象的隔离。

尽管虚拟机内省不需要改动目标虚拟机系统的任何代码与数据，但一些特定的恶意程序仍然可以检测到客户机是否正在运行在一个虚拟机环境中[12]。恶意程序还可能利用共享核实是否正确虚拟CPU（virtual CPU，vCPU）的缓存的隐蔽信道检测到是否有虚拟机在监控它的恶意行为[13]。

2.1.3 最小权限限制与隔离

隔离的运行环境可提高安全的可信性。但在普通虚拟机架构中，虚拟机之间可相互通信、共享内存。为保证安全与外界的隔离，需要切断安全所在的虚拟机与其他的虚拟机之间不必要的内存共享与通信方式。此外，安全作为虚拟机监控者，具有访问其他虚拟机内存的权限。为防止安全影响其他虚拟机的正常运行，限定安全具有最小内存访问权是另一个必要措施。

由此，安全在设计过程中需遵循以下限制：

1）安全仅与虚拟机监控器直接通信。安全对外暴露出的接口要尽可能少。本文假设其他虚拟机是不安全的，因此为减小安全的可攻击面，禁止与其他虚拟机的通信接口是有效的办法。安全仅保留与虚拟机监控器的通信接口，实现对其他虚拟机的内存读取与实时度量。

2）禁止安全与其他VM之间的内存共享机制。虚拟机监控器提供内存共享机制，允许VM之间访问对方的内存。例如，Xen中的授权表[14]等。由于安全可以借助虚拟机监控器的内存管理接口获取其他VM的内存访问权，所以对于其他内存共享方式，需加以禁止。此外，需要禁止被监控VM对安全的内存访问。比如，在Xen中，禁止被监控VM通过监控器内存管理接口、授权表等方式访问安全的内存页。

3）安全对其他VM的内存的访问权限为只读权限。如果允许安全改变其他VM的内存，则目标虚拟机的完整性或安全性很可能会被安全破坏。比如，如果安全被攻陷，则攻击者就可以利用该控制其他虚拟机。

在Xen中采用强制访问控制工具Xen Security Modules（XSM）[15]可实现虚拟机环境的强制隔离及特殊的内存授权。XSM可以控制虚拟机与虚拟机之间、虚拟机与监控器之间，以及相关资源如内存和设备之间的交互权限。使用XSM既可以禁止不必要的虚拟机通信与内存共享，也可以在无需修改目标虚拟机的前提下授予安全虚拟机对其他虚拟机的内存只读权限。

2.2 结构设计

如图2所示，完整性校验系统结构主要包括3个模块：主模块、可信状态库和虚拟机内省模块。

2.2.1 主模块

主模块负责对整个安全的管理，借助其他功能模块提供给主模块的接口，实现安全的基本功能，主要包括内存搜索、度量和校验对比。

内存搜索部分可以根据内省模块获取的内存页，对监控目标进行语义抽取和搜索定位。度量部分计算监控目标的度量值，允许实现多种度量算法。本文以缺少引用和介绍。SHA1为常用的安全哈希算法，参见：http：///wiki/SHA-1

SHA1算法为例实现原型系统。主模块的校验对比部分可以访问安全状态数据库中存储的可信度量值，与实时度量值进行比较分析。

2.2.2 可信状态数据库

可信状态数据库用于存储虚拟机可信度量值，可以包含所有有助于校验内存运行状态可信性的度量值。比如：用于校验静态代码的程序哈希值，用于校验程序的控制流完整性的程序流控制图[16]等。

本文假设度量对象的启动状态可信。可信度量值在目标对象的启动过程中初始化到数据库中。在目标对象的实时度量过程中，这些可信状态被用来校验目标对象的完整性。

2.2.3 虚拟机内省模块

安全实时度量内存中的运行对象，需要能够访问目标虚拟机的内存页，并从中抽取出内存状态信息。虚拟机内省模块借助开源工具LibVMI获得目标虚拟机的内存信息。目标虚拟机内存页的实时获取由该模块负责。该模块是安全与虚拟机监控器直接通信的唯一接口。该模块通过向虚拟机监控器发出请求，获取目标虚拟机特定的内存页内容以及基本语义信息。比如，通过内省模块可以读取目标虚拟机的虚拟CPU寄存器状态，获取内核页表、用户进程页表和特定内存页等。

3 系统原型实现

基于以上设计，本文在Xen的微小操作系统MiniOS中实现了原型系统TinyVMI，对其他客户虚拟机的完整性执行无干涉的实时内存度量。下面从库函数、XSM授权、实时校验步骤3个方面介绍实现中的一些关键技术细节。

3.1 库函数

安全的编译需要C库以及Glib库的支持，而在Xen原生的MiniOS中并没有这些库函数。最新的Xen源码树中已经提供对C库的交叉编译环境，该交叉编译环境使用Newlib作为C库。Newlib是在嵌入式系统开发中经常用到的C函数库，其中实现了标准C库最小集合以及一些基本的数学库函数，如输入输出函数、字符串操作、时间戳函数等。

Glib中定义的一些常用数据结构及其算法需要在安全中使用。但是由于Glib与Xen的MiniOS环境不能兼容，且多数复杂库函数在安全中没有用到，因此将依赖于Glib的常用函数完成自己的实现。用替代后的Glib函数的数据结构与函数示例如下。

3.2 XSM授权

在Xen中，除了Domain0之外，客户虚拟机无法直接访问其他客户虚拟机的内存。安全需要在隔离的微小虚拟机中获取其他虚拟机的内存状态。因此，借助Xen中的XSM机制可以赋予小型虚拟机必需的内存访问权限。

通过XSM的授权限制主要有两方面：1）授予安全足够的内存访问权限，使其拥有对其他虚拟机内存的只读权限；2）除此之外，禁止安全所在的轻量级虚拟机与其他虚拟机之间其他形式的通信与内存共享机制，保证该轻量虚拟机与外界的通信接口最少。

下面是利用XSM为安全定义的权限策略示例，安全被标记的策略类型为DomT_t类型。下面的策略组合允许安全以调用Hypercall的方式与Xen Hypervisor通信，并获取对其他HVM类型客户虚拟机内存的只读权限。其FLASK策略定义如下：

3.3 实时校验过程

安全执行实时完整性校验的过程如图3所示，关键环节有启动记录可信度量、安全搜索度量目标和度量与验证三部分。

3.3.1 启动时记录可信度量

可信状态数据库的度量值是在对象的启动过程中初始化到数据库中。比如对于键盘驱动程序，安全会在目标虚拟机的中断向量表初始化完成后，根据目标虚拟机的中断向量表搜索键盘驱动程序在目标虚拟机内存中的位置，获取相关的内存页，然后计算键盘驱动程序中的静态代码段与数据段，进而计算度量值并保存到可信状态数据库中。

3.3.2 安全搜索度量目标

实时完整性度量由安全主动触发执行，首先根据度量目标的虚拟机名称、目标虚拟地址确定目标物理地址，然后将物理地址的内存页映射到安全的地址空间中。这样，在安全中就可以访问目标虚拟机中度量对象的物理页面。比如，对于键盘驱动程序，首先根据目标虚拟机名称以及中断向量表偏移，经一系列地址转换与搜索，最终确定中断处理程序的物理页面。之后将内存页面映射到安全的内核空间中，然后根据程序结构，获取键盘服务程序的代码段、数据段等内容。

3.3.3 度量与验证

获取度量目标的内存信息之后，安全可以根据度量目标的定义计算目标的度量值。度量值的计算采用SHA1算法。在键盘驱动的校验过程中，被度量区域可信状态的初始化和运行时的度量使用相同度量算法。如果同一区域运行时度量的哈希值与存储的可信状态的哈希值不相同，说明该区域的状态与启动时的状态不一致，则认为键盘程序完整性遭到破坏。

4 性能分析

为评估TinyVMI的内存访问对整个系统性能的影响，本文在基于Xen Domain0的LibVMI和基于Xen MiniOS的TinyVMI中，分别实现了两组功能相同的实例程序：虚拟地址转换和内核模块遍历程序，并分别对比了两组程序在LibVMI和TinyVMI上运行的性能。硬件平台：CPU为Intel Pentium DualCore，主频2.80GHz，内存2GB。软件平台：虚拟机监控器Xen4.4.0，LibVMI0.10.1；Domain0为Ubuntu 12.04（64bit），分配内存900MB；目标虚拟机为中英全硬件虚拟机（Hardware Virtual Machine，HVM）模式的Linux Mint 15（32bit），内存700MB；基于MiniOS的原型系统分配内存32MB。

下面分别介绍在原型系统上实现的两组实例程序及其性能表现。

第一个实例是虚拟地址转换。程序以虚拟机名称和虚拟机地址作为输入，查找目标系统的内核页表，并通过获取的各级内核页表计算出最终的目标物理地址。整个过程需要多级页表的访问，因此会发生多次循环调用地址转换接口。

为对比基于Domain0的LibVMI和基于MiniOS的TinyVMI两者的运行性能，实验统计了TinyVMI和LibVMI在同一目标虚拟机的相同度量对象上完成与图中刻度不完全对应30～500个虚拟地址页首地址的转换与映射时间，统计结果如图4所示。随着访问页数的增加，TinyVMI的增长速度远远小于LibVMI的增长。此外，对于500页内存访问的平均时间进行统计，使用LibVMI的平均时间为1139μs，而使用TinyVMI仅为43.95μs。

上述结果表明，在MiniOS中实现的地址转换操作比在Domain0中实现的相同功能减少了96%的时间消耗。由此可见，对于同一个目标虚拟机的相同页地址的转换与映射，在TinyVMI中实现的性能损耗大大低于在LibVMI中的性能损耗。

内存页访问时间统计为何不是正好是1～横坐标缺刻度，可以这样标记。 只要（a）的横坐标刻度值在1～30，（b）的横坐标在1～500之间就可以；两个坐标的刻度都是线性均匀分布的刻度，不是指数刻度等其他类型的刻度。

另一个实例是内核模块的访问程序。本实例程序以虚拟机名称作为输入，可以搜索目标虚拟机的内核空间并获取已被加载到内核的内核模块名称，测试TinyVMI和LibVMI在遍历Linux客户机内核中所有模块名称所需要的时间。实验结果显示，使用LibVMI遍历一个客户机所有内核模块名称的平均时间为30.0ms，而TinyVMI仅为2.2ms。结果表明TinyVMI可以节省LibVMI所需时间的92%，因此，TinyVMI原型系统在内存分析上同样具有更好的性能。

综上所述，在微小操作系统中实现虚拟机内省并实时监测目标虚拟机的内存，相对于在Domain0中实现该技术，可以节省92%以上的内存访问时间，有效减小了内存监测对整体性能的影响，提高系统的运行效率。

5 结语

在商业化操作系统实现虚拟机内省来监控其他系统内存的方法对平台的性能影响很大，而且显著增大了系统可信代码基。本文提出了一种在微小操作系统中实现虚拟机内省，并用来监控商业化目标系统的系统完整性的体系架构，实现了原型系统，并对原型系统的内存监控行为作了评估，取得了显著的性能提升。

虽然当前工作实现了在微小系统中对大型商业化操作系统的实时内存度量，但该平台的安全功能还有很大的扩展空间，在设计架构上同样有很大的扩展余地。比如，安全所监控的目标内存区域，以及监控的策略与方法，都定义并配置在安全中。这类工作可以借助安全规则来实现，所以后续需提出具有足够描述能力的规则定义与实施模型，以满足更多的内存监控与安全防护需求，进一步优化平台的功能与效率。

参考文献：

[1]PK G， BUTTYN L， BENCSTH B. A survey of security issues in hardware virtualization [J]. ACM Computing Survey， 2013， 45（3）： Article 40.

[2]CHAWLA S， NIGAM A， DOKE P， et al. A survey of virtualization on mobiles [C]// ACC 2011：Proceedings of the First International Conference on Advances in Computing and Communications， Communications in Computer and Information Science， LNCS 191. Berlin： Springer， 2011： 430-441.

[3]PAYNE B D， de CARBONE M D P， LEE W. Secure and flexible monitoring of virtual machines [C]// ACSAC 2007： Proceedings of the TwentyThird Annual Computer Security Applications Conference. Piscataway： IEEE， 2007： 385-397.

[4]PAYNE B D. Simplifying virtual machine introspection using LibVMI， SAND20127818 [R/OL]. [2014-12-01]. http：//prod.sandia.gov/techlib/accesscontrol.cgi/2012/127818.pdf.

[5]HIZVER J， CHIUEH T. Realtime deep virtual machine introspection and its applications [C]// VEE 2014： Proceedings of the 10th ACM SIGPLAN/SIGOPS International Conference on Virtual Execution Environments. New York： ACM， 2014： 3-14.

[6]XIA Y， LIU Y， CHEN H. Architecture support for guesttransparent VM protection from untrusted hypervisor and physical attacks [C]// HPCA 2013： Proceedings of the 2013 IEEE 19th International Symposium on High Performance Computer Architecture. Piscataway： IEEE， 2013： 246-257.

[7]SHAW A L， BORDBAR B， SAXON J， et al. Forensic virtual machines： dynamic defence in the cloud via introspection [C]// IC2E 2014： Proceedings of the 2014 IEEE International Conference on Cloud Engineering. Piscataway： IEEE， 2014： 303-310.

[8]HARRISON K， BORDBAR B， ALI S T T， et al. A framework for detecting malware in cloud by identifying symptoms [C]// EDOC 2012： Proceedings of the 2012 IEEE 16th International Enterprise Distributed Object Computing Conference. Piscataway： IEEE， 2012： 164-172.

[9]GUTTMAN B， ROBACK E A. An introduction to computer security： the NIST handbook [R]. Gaithersburg： National Institute of Standards and Technology， 1995.

[10]SINGARAVELU L， PU C， HARTIG H， et al. Reducing TCB complexity for securitysensitive applications： Three case studies [J]. ACM SIGOPS Operating Systems Review， 2006， 40（4）： 161-174.

[11]POPURI S. A tour of the MiniOS kernel [EB/OL]. [2014-12-01]. http：//www. cs. uic. edu/～ spopuri/minios. html.

[12]PALEARI R， MARTIGNONI L， ROGLIA G F， et al. A fistful of redpills： how to automatically generate procedures to detect CPU emulators [C]// WOOT 2009： Proceedings of the 3rd USENIX Conference on Offensive Technologies. Berkeley： USENIX Association， 2009： 2-2.

[13]RISTENPART T， TROMER E， SHACHAM H， et al. Hey， you， get off of my cloud： exploring information leakage in thirdparty compute clouds [C]// CCS 2009： Proceedings of the 16th ACM Conference on Computer and Communications Security. New York： ACM， 2009：199-212.

[14]CHISNALL D. The definitive guide to the Xen hypervisor [M]. Upper Saddle River： Pearson Education， 2008： 59-74.缺少引用页码

[15]COKER G. Xen security modules （XSM） [EB/OL]. [2014-12-01]. http：///files/summit_3/cokerxsmsummit090706.pdf.

[16]WANG Z， JIANG X. Hypersafe： A lightweight approach to provide lifetime hypervisor controlflow integrity [C]// SP 2010： Proceedings of the 2010 IEEE Symposium on Security and Privacy. Piscataway： IEEE， 2010： 380-395.