安全隔离的安卓应用虚拟化框架设计与实现

侯俊行，杨哲慜，杨 珉

(复旦大学 软件学院，上海 201203) E-mail ：yangzhemin@fudan.edu.cn

1 引 言

Android是最受欢迎的移动操作系统.据IDC报告显示，2017年第一季度，Android已占据全球市场份额的85.0%[1].Android拥有丰富的应用，截至2018年6月，其官方市场Google Play中应用数已达到3，300，000个[2].用户在使用Android应用时，存在对这些应用进行定制化的需求.例如，运行多个Twitter应用实例以同时登陆多个账号，改变游戏Pokeman Go获得的地理位置信息.然而，越来越多的应用使用混淆、重打包检测等技术，这加大了应用被修改的难度.

用户对应用定制化需求的不断增长，促使Android平台上应用虚拟化的流行.一个虚拟化框架(宿主应用)，可以在内部创建一个受控的虚拟空间，在此空间内能够运行任意Android应用(目标应用).目标应用无需在系统内安装，并可同时运行多个实例.此外，无需重打包，框架便能方便地对目标应用进行修改，达到应用定制化目的.目前，“平行空间[3]”作为最受欢迎的虚拟化框架，在Google Play中的下载量已经超过了1，000万次.

然而，前人研究工作[4]发现，现有虚拟化框架存在以下安全问题：在存储隔离方面，目标应用可以任意读取框架内其它应用私有文件，造成隐私数据的泄露；在权限隔离方面，框架申请了过多权限，目标应用在运行时能够继承这些权限，进行恶意提权.

在原生Android中，系统为每个应用赋予唯一的用户ID(UID)，并与之进行绑定.基于应用UID，系统为每个应用构建一个沙箱，实现存储和权限的隔离.在应用虚拟化使用场景下，框架内可能同时运行多个目标应用实例，但系统却无法为每个实例创建不同的沙箱.在同一沙箱内运行所有的目标应用实例时，系统对其中一个实例赋予的权限会扩散给沙箱内所有的实例，进而使其他实例被过度授权.然而，在对目标应用进行定制化时，定制化代码只有与应用运行在同一沙箱内，才能够修改目标应用的行为.因此，Android原生沙箱机制无法直接用于应用虚拟化场景.

现有针对应用虚拟化的沙箱隔离方案中，Boxify[5]将目标应用运行在不同的被隔离进程[6]中，由Boxify对应用所使用的函数调用进行拦截和访问控制，以达到安全隔离目的.但是，Boxify需要预先申请所有的系统权限，增大了受攻击面.并且，Boxify同样无法对定制化代码进行隔离.此外，Boxify实现的虚拟化方案并不完善，系统内第三方应用无法使用隐式Intent[7]启动Boxify内的目标应用.

基于上述情况，本文设计并实现了一个安全隔离的应用虚拟化框架SecureAppV.首先，我们通过修改系统，将Android应用沙箱分配以及权限管控粒度细化为应用组件级别，解决了原本必须通过安装多个应用才能获得不同沙箱的难题.基于此，框架为每个目标应用实例的运行创建不同的沙箱，并支持用户使用自定义规则对沙箱权限进行管理，以实现目标应用存储和权限的隔离.同时，SecureAppV利用宿主应用对沙箱间通讯进行代理转发，并使用自定义规则对转发过程进行管控.在定制化代码和目标应用位于不同沙箱的情况下，实现应用定制目的.最后，我们为系统增加组件热更新机制，应用在无需重装的前提下，能够对自身组件的IntentFilter属性进行修改.框架利用此机制，处理第三方应用隐式Intent的请求.

本文所修改Android版本为android-6.0.1_r77，编译后的系统和SecureAppV框架运行在Nexus 5测试机之上.为了测试框架的隔离效果，本文选取平行空间等5个具有代表性的虚拟化应用，以及VirtualApp[8]、DroidPlugin[9]两个开源框架与SecureAppV进行对比.实验结果表明，仅有SecureAppV能够对框架内目标应用存储和权限进行有效隔离.为了测试SecureAppV的可用性，本文将8个主流应用运行在框架内.实验中，8个(100%)应用均能正常运行，且在运行过程中，0个(0%)应用出现崩溃现象.在性能测试实验中，SecureAppV对框架内运行的应用仅带来5.92%的性能损失，具有较强的实用性.

2 背景与相关工作

2.1 安卓隔离与访问控制机制

Android使用沙箱机制对应用代码和数据进行隔离.在应用安装时，系统为每个应用赋予唯一的UID，并与之进行绑定.应用运行在独立进程之中，拥有完整的Dalvik/ART虚拟机实例，从而实现代码的隔离.应用使用系统调用获取文件资源时，内核基于进程UID实现文件目录的访问控制，从而为每个应用开辟私有空间，实现数据的隔离.这个基于Linux进程隔离机制创建的环境被称为沙箱.

此外，Android使用权限机制对应用行为进行管理.在程序进行敏感操作或者访问受保护资源时，由系统对应用的权限进行检查.权限按照保护级别分为正常权限、危险权限和签名权限三种类型.其中，正常权限在清单文件中声明后，在应用安装时被系统默认授予，无需用户授权，被称为安装时权限.危险权限也被称为运行时权限，应用申请运行时权限时，在清单文件中显式声明后，还需要在运行时使用方法Activity.requestPermissions()动态申请.应用包名以及应用所请求权限会被包装进一个Intent对象，由系统应用安装器所处理.应用安装器会弹出一个权限授权对话框供用户进行选择，并将用户授权结果交予活动管理服务AMS，由AMS请求使用包管理服务PMS进行权限授权结果的记录.对于签名权限的获取，应用需要拥有与系统相同的签名证书.

2.2 安卓应用虚拟化

本文中所指应用虚拟化是一种在应用层实现的虚拟化方案.它基于动态代码加载，使用反射、代理等技术手段在宿主应用内，为目标应用创建运行所需的上下文环境.

使用虚拟化框架，用户能够方便地对目标应用进行定制化.框架在运行时动态加载目标应用代码，运行在自身进程空间之内.目标应用无需在系统中进行安装，并可同时运行多个实例.同时，框架对目标应用与系统间的交互进行代理.例如，应用通过地理位置服务LocationManagerService在宿主进程内的本地代理对象LocationManager与之进行通信.宿主应用通过替换本进程内远程服务的本地代理对象，修改服务中方法getLastKnownLocation()的返回值，可以改变应用获取的真实地理位置信息.

2.3 现有虚拟化框架安全问题分析

图1为应用虚拟化框架结构图.其中，框架与目标应用运行在同一沙箱内，框架对目标应用的请求进行代理，系统无法对请求的发起者进行区分.因此，目标应用与框架具有相同的存储访问能力和权限授权状态.任意目标应用都可以读取框架内其它应用的私有文件，继承框架授权的所有权限，进行敏感操作或访问系统保护资源.

2.4 相关工作

现有沙箱隔离方案，主要分为应用层实现[10-13]和系统级扩展[14-17]两种类型.

应用层方案中，Aurasium[10]为Android平台提供了使用时权限动态授予机制.通过对应用安装包进行二进制重写，Aurasium能够拦截应用内所有权限的使用行为，并在拦截到权限使用的行为后，弹出对话框要求用户进行显式的权限授予.RetroSkeleton[11]重写安装包后插入分析代码，使用静态以及动态方式分析函数调用，并支持用户自定义规则对应用行为进行监控和拦截.应用层解决方案通过应用重打包，加入特定监控代码，对应用行为进行约束.由于应用与监控代码运行在同一个沙箱中，它们之间缺乏安全隔离，攻击者可以使用本地代码等方式篡改或者绕过上述管控措施.此外，重打包会破坏应用原有的签名.

系统级方案中，DeepDroid[14]通过对Android核心系统服务和关键函数进行动态插桩，以阻止不信任应用发起的调用行为.FireDroid[15]通过动态插桩Zygote和系统启动代码，对第三方或者预装应用行为进行监控，根据用户定义规则进行拦截.系统级解决方案无需对应用进行修改，破坏其原有签名；基于并扩展Android原生沙箱机制，具有很强的隔离效果.但此类方案无法为宿主应用内多个目标应用运行实例创建不同沙箱，无法在定制化代码隔离的情况下对目标应用进行修改，因此无法用于应用虚拟化场景.

2.5 威胁模型

本文考虑以下两种攻击情形：恶意应用运行在虚拟化框架中，读取框架内其他应用的私有文件；恶意应用在未取得相关权限授权的情况下，通过继承框架权限，进行敏感操作或者访问系统保护资源.本文认为系统及其内核是安全的，恶意应用无法攻破系统现有安全保护措施.

3 SecureAppV总体框架

图2为SecureAppV框架概览图.其中，框架按照功能被划分为以下三个模块：

UID分配模块.为了能够在宿主应用运行时创建UID不同于自身的沙箱，系统首先为其分配多个UID.我们选择在宿主应用清单文件内增加特定的标签，以便应用在安装时，系统能够区分出宿主应用.接下来，系统为宿主应用分配多个UID，处理UID对应目录创建的问题.

沙箱管理模块.SecureAppV将每个目标应用实例运行在不同的沙箱内，并使用用户自定义规则对每个沙箱的权限进行管控，实现沙箱间存储和权限的隔离.沙箱间能够按照用户自定义规则进行灵活的通讯.基于此，定制化代码在与目标应用位于不同沙箱的情况下，依然能够对应用进行修改.

图2 SecureAppV框架概览Fig.2 Overview of SecureAppV framework

虚拟化管理模块.在新建的沙箱内，框架主要需要处理以下三个问题：

1)如何从外部动态加载任意目标应用或定制化代码.

2)如何对应用组件生命周期进行管理.

3)如何处理第三方应用使用隐式Intent启动框架内目标应用的请求.

4 SecureAppV设计与实现

4.1 UID分配模块

Android使用包管理服务PMS对应用进行安装、卸载和查询.在应用安装时，PMS通过解析应用安装包内清单文件，获取应用使用包名、声明组件、申请权限等信息.之后，PMS为该应用分配全局唯一的UID(此处，不考虑共享UID情况)，创建UID对应的文件目录.最后，PMS将应用信息以及应用分配的UID写入配置文件中.因此，在UID分配阶段，我们需要对PMS进行修改，在宿主应用安装时为其分配多个UID，创建UID对应的文件目录，最后将应用分配的所有UID进行存储.

4.1.1 宿主应用标记与解析

首先，我们在宿主应用清单文件中增加特定的标签，以便应用在安装时，PMS能够区分出宿主应用.如图3所示为增加的标签，该标签有“android：name”和“android：value”两个属性.其中，属性“android：name”值设为预定字符串“dynamicUID”，表明应用需要申请多个UID；属性“android：value”值“2”指定额外申请UID的数量.此外，我们还需修改PackageParser.parseMetaData()方法，以对此标签进行解析处理.

图3 宿主应用清单文件标记
Fig.3 Mark in the Manifest file of host app

4.1.2 UID分配

4.1.3 私有目录创建

应用分配UID之后，PMS通过socket方式向守护进程Installed发送命令，为应用创建私有目录并设置文件访问权限.我们通过修改Installed，为目标应用也创建相应的文件目录.图4为宿主应用的私有文件目录.其中，宿主应用UID为10052，并申请到10053和10054两个额外UID.目录10053和10054作为目标应用私有文件的根目录，文件所有者以及用户组均与UID相同，组外用户只拥有文件的执行权限，从而实现目标应用存储隔离.

图4 宿主应用私有文件目录Fig.4 Private file directories of host app

最后，我们修改Settings.writePackageLPr()方法，将宿主应用申请的所有UID写入/data/system/目录下文件packages.xml做持久化存储.

4.2 沙箱管理模块

活动管理服务AMS负责应用进程的管理以及权限的检查任务.我们通过对AMS进行修改，在宿主应用运行时动态创建UID不同于宿主应用的进程沙箱，根据用户自定义规则对沙箱授权权限进行管理.

4.2.1 沙箱创建

AMS在启动应用组件时，如果组件所在进程尚未创建，AMS会请求Zygote进程为其创建运行所需的进程.Zygote进程是所有Android应用进程的父进程.它在/dev/socket目录下创建一个名为zygote的本地套接字，在监听到新进程创建请求时，Zygote进程使用系统调用fork()新建一个子进程，并设置子进程的UID.

宿主应用通过启动应用内Service组件创建新进程，并通过此组件与新进程进行通讯.创建过程中，AMS会向PMS请求包含Service组件信息的ServiceInfo对象.使用此对象，AMS能够获取应用对应的ApplicationInfo对象，从而得到应用分配的所有UID.我们通过修改AMS，创建Service组件运行所需的进程后，设置进程UID为宿主应用申请的额外UID，从而创建出UID不同于宿主应用的进程沙箱.

4.2.2 权限设置

为了保证目标应用能够正常运行，我们需要为应用赋予相应的权限.PMS为每个应用生成一个PackageSetting类型对象，对象中记录着应用在清单文件中声明的权限以及权限授权状态.AMS在进行权限检查时，将待检应用UID以及所检查权限交由PMS进行处理.PMS的checkUidPermission()方法根据UID检索应用对应的PackageSetting对象，返回对象中保存的待检权限的授权状态.我们在PMS内建立目标应用UID与PackageSetting对象的映射关系.其中，PackageSetting对象记录的权限授权状态按照用户自定义规则进行设置，这样便完成了目标应用权限的设置.

图5 用户自定义权限规则Fig.5 User defined permission rules

SecureAppV支持用户自定义规则对目标应用权限进行设置.图5为自定义权限规则.标签使用包名指定设置目标对象，子标签和分别对目标应用允许或者禁止使用的权限进行声明.默认规则下，SecureAppV按照应用清单文件中声明的权限对目标应用进行赋值.其中，安装时权限被默认授予，运行时权限需要用户授权来授予.为此，我们在运行时权限的请求中加入目标应用的UID身份信息，以便PMS根据UID找到应用相应的PackageSetting对象，继而进行权限授权的记录.

4.2.3 沙箱间通讯

对于宿主应用创建的沙箱，SecureAppV支持沙箱之间进行通讯，由宿主应用根据用户自定义规则对通讯进行代理转发.基于此，定制化代码在与目标应用位于不同沙箱的情况下，代码依然能够对应用进行修改.目前，框架支持定制化代码修改目标应用访问的系统服务以及应用内的文件.

对于系统服务的修改.Android提供的系统服务需要在ServiceManager中进行注册，应用可使用服务名获取远程服务在本进程内的Binder代理对象.之后，应用使用这些代理对象访问远程系统服务.SecureAppV支持定制化代码替换目标进程内系统服务的本地代理对象，以达到修改应用访问系统服务的目的.如图6所示为定制化代码创建的系统剪贴板服务的代理对象HookedClipboardBinder，通过继承类IClipboard.Stub实现服务提供的功能.该对象重写了getPrimaryClip()方法，用以返回特定的剪贴板内容.框架向定制化代码提供了接口，该接口能够将代码创建的可序列化传输对象HookedClipboardBinder，经宿主应用传输给目标应用.在目标进程内，框架使用反射等技术手段对剪贴板服务的本地代理对象进行替换.最终，目标应用得到的剪贴板内容将始终为字符串“you are hooked”.

图6 定制化代码创建的服务代理对象Fig.6 Proxy object of service created by customization codes

对于文件的修改.SecureAppV使用ARM Inline Hook[18]技术，对定制化代码文件操作使用的系统调用进行拦截，并将拦截到的调用名和参数发送至宿主应用，由宿主应用在目标进程内代为执行.例如，系统调用int chown(const char *path，uid_t owner，gid_t group)可以改变文件或目录的所有者和所属用户组.此调用接受三个参数，第一个参数path为所修改文件或目录的路径；第二个参数owner为修改后的用户ID；第三个参数group为修改后的用户组ID.当定制化代码修改目标应用文件test.txt所有者时，最终系统使用chown调用完成该操作.框架拦截到此系统调用后，将调用名owner和调用参数，包括文件路径以及修改后的用户ID和用户组ID发送至宿主应用.宿主应用使用目标进程内的Service组件执行chown()系统调用，从而完成对目标应用test.txt文件所有者的修改.

图7为用户自定义的通讯规则.其中，标签的source和sink属性分别为定制化代码以及目标应用所属包名.子标签指定了定制化代码能够修改的服务名称；子标签通过文件名或文件后缀指定定制化代码允许修改的目标应用文件.

图7 用户自定义通讯规则Fig.7 User defined communication rules

4.3 虚拟化管理模块

4.3.1 动态代码加载

Android应用安装包是一个Zip格式的压缩文件，由应用清单文件、DEX可执行文件和资源文件打包而成.应用在正常安装后，安装包内代码和资源文件会存放在系统固定目录内.应用主线程ActivityThread内维护着一个LoadedApk类型字段，LoadedApk存有加载应用使用的类加载器.系统使用此加载器，从指定目录加载应用代码和资源文件.为了能够从指定位置加载目标应用或者定制化代码，我们使用DexClassLoader类加载器，在生成类加载器实例时传入所要加载代码的位置信息，并加入到主线程之中.

4.3.2 组件生命周期管理

Android中，由AMS负责对应用组件生命周期进行管理.AMS运行在系统进程system_server内，使用Binder机制与应用进行通讯.AMS向应用发送控制命令消息后，由应用主线程对这些消息进行处理，完成组件类加载或者生命周期函数的回调.应用通过本进程内AMS服务的本地代理对象ActivityManagerNative与AMS进行交互.

图8为SecureAppV对目标应用Activity组件生命周期处理的过程.对于其他组件，本文限于篇幅进行了省略.其中，ActivityManagerProxy和ActivityThreadProxy分别是ActivityManagerNative和ActivityThread的代理对象，我们对目标进程内原有对象进行替换，以便对目标应用与AMS之间的交互以及应用主线程操作进行拦截.桩组件是在宿主应用内预先声明的Activity组件，并加载到目标进程之中.首先，在目标进程内使用startActivity()方法启动目标应用Activity组件(①)时，Intent对象内携带待启动组件的信息.ActivityManagerProxy拦截到此方法调用后，检索可用桩组件(②)，将Intent内待启动目标应用组件替换为可用桩组件(③)，并维护桩组件与目标应用组件间的映射关系(④).之后，交由AMS进行组件的启动(⑤)，以绕过目标组件未声明使用的限制.AMS完成组件启动准备工作后，向目标应用发送启动桩组件的命令(⑥).ActivityThreadProxy拦截此命令后，根据映射关系完成启动对象的转换(⑦)，启动相应的目标应用组件(⑧)，完成组件类的实例化(⑨).此后，由ActivityThreadProxy和桩组件共同完成目标组件生命周期函数的管理.例如，AMS需要销毁桩组件时，请求主线程调用onDestroy()函数(⑩).ActivityThreadProxy根据映射关系，最终回调目标应用组件onDestroy()生命周期函数().

图8 组件Activity生命周期管理Fig.8 Lifecycle management of Activity component

为了能够对隐式Intent做出处理，SecureAppV使用桩组件并设置相应的Intent Filter属性，对第三方应用启动目标组件的隐式Intent进行响应()，并完成匹配().在应用虚拟化场景下，加载的目标应用具有任意性，无法预先对桩组件的Intent Filter属性进行设置.由于PMS存储应用组件以及组件的Intent Filter属性，使用AIDL定义PMS对外提供的接口.因此，我们通过修改相应的AIDL文件(IPackageManager.aidl)，增加更新组件Intent Filter属性值的方法int updateActivityIntentFilter(String name，List newFilters).其中，参数name为待更新Activity组件的名称，newFilters为组件更新后的Intent Filter属性.基于此，桩组件能够根据加载目标应用对自身Intent Filter属性进行热更新，对相应隐式Intent做出响应.用户在选择启动桩组件(存在多个匹配结果)后，AMS将启动请求交由目标进程主线程进行处理()，ActivityThreadProxy根据隐式Intent匹配规则()，找出相应目标应用组件，完成组件的启动工作().

5 实验与评估

本节将通过实验对SecureAppV框架的安全性、可用性以及性能进行评估.其中，安全性评估测试框架能否对目标应用存储和权限进行隔离，定制化代码在不同沙箱的情况下对目标应用的定制效果；可用性评估测试现实中应用能否在框架内正常运行；性能评估测试应用在框架内运行产生的额外性能开销.

本文所修改Android版本为android-6.0.1_r77，内核版本3.40，编译后运行在Nexus 5测试机之上，其处理器为高通骁龙800，2.3GHz主频，运行内存大小为2G.

5.1 目标应用隔离测试

对于实验对象的选择，本文根据下载量在Google Play中选取平行空间等5个具有代表性的虚拟化应用，从Github中下载开源框架VirtualApp和DroidPlugin源码编译后，与SecureAppV进行对比.表1为所选虚拟化应用.其中，第一列为所选应用包名，第二列为应用在Google Play中的下载量，第三列为应用申请的系统权限数量.

表1 对比实验所选虚拟化应用Table 1 Virtualization apps chosen to compare

在本实验中，本文使用开发的攻击测试应用分别在上述框架内运行，对框架内目标应用间文件、权限以及系统服务进行隔离测试.

文件隔离测试.在应用虚拟化框架下，目标应用内部文件都保存在框架私有目录的子目录内.例如，对于双开空间(com.ludashi.dualspace)，目标应用内部文件存储在框架私有目录/data/data/com.ludashi.dualspace/的子目录virtual/data/app/target_package_name/下.攻击应用通过绝对路径和相对路径两种方式尝试读取框架内其他应用私有目录内文件.如果读取失败，证明框架进行了文件隔离；读取成功，则证明框架未对目标应用文件进行隔离.

权限隔离测试.攻击应用在未对权限INTERNET显式申请的情况下，进行网络访问操作.其中，各个框架均预先申请了INTERNET权限.SecureAppV对测试应用使用默认权限规则，即按照应用清单文件内声明的权限(未声明INTERNET权限)进行设置.如果访问操作成功，证明框架未进行权限隔离，攻击应用能够继承框架申请的权限；操作失败，则证明框架进行了权限隔离.

服务隔离测试.Android应用通过访问系统服务可以进行大量敏感操作.为了隔离不同应用数据，服务会对应用身份信息进行验证.对于系统服务隔离测试，攻击应用通过访问系统服务AccountManagerService，尝试获取框架内其他应用(Twitter)注册的账户信息.如果访问成功，证明框架未对系统服务的使用进行隔离；访问失败，则证明框架对目标应用使用的系统服务进行了隔离.

表2 隔离实验测试结果Table 2 Results of security testing experiment

其中“×”表示可以突破安全隔离，“√”表示无法突破隔离，“⊗”表示现有隔离措施可以被绕过

表2是隔离测试的实验结果.在文件隔离测试中，只有SecureAppV能够对目标应用之间文件进行隔离.由于不同应用运行在不同UID之下，由内核目录访问控制实现的隔离无法被绕过.对于平行空间，攻击应用使用绝对路径和相对路径均无法对其他应用私有目录下文件进行访问.我们对其进行人工分析后发现，平行空间对应用访问的文件路径进行了判断，当路径前缀指向其他应用私有目录时，框架会禁止文件访问的操作.我们通过在攻击应用自身目录下，创建所要访问应用私有文件的软链接[19]，使用此链接绕过文件路径访问的限制.在权限隔离测试中，仅有SecureAppV对攻击应用权限进行隔离.在其他框架内，攻击应用在未申请权限INTERNET情况下，通过继承框架权限成功进行了网络访问操作；在服务隔离测试中，除了框架SecureAppV，攻击应用通过访问服务AccountManagerService得到框架内Twitter应用注册的账户信息.

5.2 定制化代码隔离测试

在该实验中，我们测试SecureAppV框架在定制化代码隔离的情况下，对目标应用修改的效果.

图9 目标应用获得的虚拟位置信息Fig.9 Mock location get by target app

由上文可知，应用通过地理位置服务的本地代理对象访问此服务.其中，服务提供的getLastKnownLocation()方法能够使用GPS定位获取当前所处地理位置信息.定制化代码通过继承类ILocationManager.Stub创建服务的代理对象，并重写此方法以修改应用获得的地理位置信息.同时，我们增加用户自定义规则以允许定制化代码对目标进程内地理位置服务的本地代理对象进行替换.实验结果如图9所示.其中，左半图为目标应用(高德地图)在测试机中运行获得的真实地理位置(上海)，右半图为应用运行在框架内获得的虚拟位置信息(纽约).

5.3 可用性测试

对于实验对象的选择，本文按照应用分类，从购物、新闻、旅游、社交、音乐、出行、办公、游戏分类下，各自挑选了一个流行应用进行测试.

表3 应用运行测试结果Table 3 Results of application running

在该实验中，我们将所选的8个应用运行在SecureAppV框架内，并使用自动化测试工具Monkey[20]，对每个待测应用发出1000个用户交互事件，记录应用运行情况.表格3为测试结果.结果显示，实验所选应用均能在框架内正常运行，并且运行时未出现应用崩溃的异常情况.

5.4 性能测试

本实验主要测试应用在SecureAppV框架内运行造成的性能损耗.本文选择安兔兔、鲁大师、Geekbench以及PassMark作为基准测试应用.我们将这些基准测试应用在测试机Nexus5和SecureAppV内分别运行10次，得出每个基准测试应用性能得分的平均值，计算性能损失的百分比.

表4 性能测试结果(10次)Table 4 Results of overhead test(10 times)

表4为性能测试结果.其中，基准测试应用安兔兔运行10次后，在测试机中性能得分平均值(ScoreNexus5)为49562，在框架SecureAppV中得分平均值(ScoreSecureAppV)为48010，降低了1552.我们使用公式，性能损耗=(ScoreNexus5-ScoreSecureAppV)/ScoreNexus5计算得出SecureAppV带来了3.13%的性能损耗.在剩余3个测试中，SecureAppV分别造成了4.35%、5.02%和11.16%的性能损失，其总体平均值为5.92%.实验结果表明，SecureAppV带来较低的性能损失.

6 总 结

本文设计并实现了一个安全隔离的应用虚拟化框架SecureAppV，该框架能够在满足虚拟化使用场景的前提下，对目标应用存储和权限进行隔离.此外，框架对现有虚拟化方案进行了完善.实验结果表明，SecureAppV在保证安全性的同时，具有较高的可用性，仅造成5.92%的性能损失.