1、移动虚拟化技术与Android安全方案目前主要的移动安全威胁应用安全威胁金融支付威胁企业业务威胁个人应用威胁-游戏。个人隐私数据安全威胁个人隐私数据企业业务数据移动安全的两大隐患应用对应用对 应用的应用的 攻击攻击应用对应用对 数据的数据的 攻击攻击终端侧主要的安全解决方法隔离 隔离 隔离 应用 系统 数据虚拟化技术是终端侧实现隔离的基础技虚拟化技术是终端侧实现隔离的基础技术术Android 虚拟化类型Hypervisor (双系统)App Wrapper(应用打包)Framework Virtualization(框架虚拟化)这一刀切在哪里App WrapperFramework Virtu
2、alizationHypervisorHypervisor 技术方案-基于基于CPU和内核的准虚拟和内核的准虚拟化化(Paravirtualization)-主要工作集中在主要工作集中在Host Kernel,Guest Kerne l和和HAL-应用、框架、库存应用、框架、库存Runtime基本不受影响基本不受影响-性能和体验良好性能和体验良好-VM之间高度隔离之间高度隔离-开发量大开发量大-与硬件高度相关与硬件高度相关，需针对硬件移植，需针对硬件移植-VM之间资源共享困难之间资源共享困难-对硬件资源要求高对硬件资源要求高 优点优点 缺点缺点App Wrapper 技术方案技术方案-针对针对
3、Android App的安全封装的安全封装-为为App提供或替换提供或替换API，提供互相隔离的，提供互相隔离的 服服务务-对操作系统要求低对操作系统要求低-无特殊硬件要求无特殊硬件要求-轻量轻量-安全性差，存在大量共用的服务和资源安全性差，存在大量共用的服务和资源-App需改造或重新打包，对需改造或重新打包，对App兼容性差兼容性差，对资源有很多限制，对资源有很多限制 优点优点 缺点缺点Framework Virtualization-对对APP兼容性高，不需要移植兼容性高，不需要移植-应用隔离和资源共用可以调整应用隔离和资源共用可以调整-对硬件无特殊要求对硬件无特殊要求-针对不同硬件和针对
4、不同硬件和Android发行版仍有发行版仍有一些移植的工作量一些移植的工作量-HAL的资源共享和调度还有一定的工的资源共享和调度还有一定的工 作作需要做需要做 技术方案技术方案-利用利用LXC，namespace等内核技术创等内核技术创造多个互相隔离的进程环造多个互相隔离的进程环 境境(namespace)-在隔离的环境分别运行服务和在隔离的环境分别运行服务和APP-改造改造HAL和服务以公用硬件资源和实和服务以公用硬件资源和实 现必要的现必要的namespace间通讯间通讯 优点优点 缺点缺点Hypervisor vs Framework VirtualizationXen(有硬件辅助),H
5、ypervisorkvm(有硬件辅助),HypervisorLxc(原生linux),Framework Virtualization硬件辅助的Hypervisor模式ARMX86VMMYYvIRQ（后期加上）YYvMMU（后期加上）YYvIOMMU（后期加上）YY硬件辅助的Hypervisor模式VMMVIRTUAL MACHINE MONITORVIROVIRTUAL INTERRUPT REQUESTVMMUVIRTUAL MEMORY MANAGEMENTVIOMMUVIRTUAL IO MMU硬件辅助下Hypervisor的实现原理15/7/1315/7/13硬件辅助下Hypervi
6、sor的实现原理Hypervisor性能测试15/7/13Bare Metal A Bare Metal BBare Metal AvgKVM AKVM BKVM AvgKVM to BareMetal相对裸机Xen AXen BXen AvgXen to Bare MetalC-Ray35.3235.3835.3535.6435.6835.660.87%36.1336.1336.132.16%POV-Ray230.05229.99230.02232.74232.14232.441.04%236.33235.45235.892.49%Smallpt1601601601621621621.23%
7、168167167.54.48%BlowGish302830243026299329902991.5-1.15%283928732856-5.95%DES737400073756677374833.5727066772730007271833.5-1.42%685866769636676911167-6.71%MD5495684952849548488824891748899.5-1.33%464284687946653.5-6.20%OpenSSL397.73397.63397.68394.6393.3393.95-0.95%387.5389388.25-2.43%7-Zip12483124
8、5212467.5121961206312129.5-2.79%118541190411879-4.95%Timed MAFFT Alignment 7.767.87.787.787.817.7950.19%8.58.348.427.60%CLOMP3.33.33.33.283.293.285-0.46%3.093.163.125-5.60%PostMark3658367636673791385738244.11%320532053205-14.41%性能降低1.85%6.31%性能表现很好，是吧？请注意，测试所用是功能软件（如 加密，解密等。请看下边一个虚拟网卡的IRQ性能测试分析在所有硬件
9、辅助都已经使用的情况下，网络中断响应能力已经下降5 0%核心是:I/O若存在大量的设备I/O性能会更加劣化移动虚拟化技术交互是移动设备的核心，所以,存在大量的 I/O.所以我们现在选择 lxc,不是kvm,不是xen结构示意appappframeworkframeworkliblibHALHALappappframeworkframeworkliblibHALHALappappframeworkframeworkliblibHALHALkernelkerneldevicedevice namespacenamespacedevicedevice driversdriverscgroupcgro
10、upmount,mount,net,utc,net,utc,user,IPC,pid user,IPC,pid namename spacespace用户层用户层内核层内核层增加device namespace支持基于device namespace更改设备驱动 使用mount namespce使用pid namespace使用所有linux kernel中存在的namespace 使用cgroup控制资源而后,我们有了containers15/7/13我们完成了 containers控制中心,create,start,stop,info,destroy,etc.containers交互代理.
11、新的device namespace 修改所有相关linux kernel device drivers所以，合二为一方案说明 新平台移植只需修改linux kernel平台相关device drive 原平台各版本的android原则上不需修改 同时启动不同版本的android需额外存储空间约3 3 0 M 同时启动相同版本的android不需额外存储空间 每多启动一个android新增约1 7 0 M 内存 每多启动一个android性能损失约%0.1(粗测)测试15/7/13我们正在做向更多的手机移植我们的方案新的FOTA机制新的D D M S 支持samsung s4,nexsus 5,定制 手机我们也许会做 ARM/KVM,加入VFIO，以及所有设备virtIO化，到这个时候I/O 将不再成为瓶颈安全吗？Hypervisor：虚拟机逃 逸FrameworkVirtualization:内核漏洞参考 http:/www.linux-kvm.org/page/KVM_Forum_2014 http:/systems.cs.columbia.edu/files/wpid-asplos2014-kvm.pdf https:/major.io/2014/06/22/performance-benchmarks-kvm-vs-xen/https:/encrypted-
