2018, Vol. 29
2. 中国信息安全测评中心, 北京 100085;
3. Singapore Management University, Singapore 178895, Singapore
2. China Information Technology Security Evaluation Center, Beijing 100085, China;
3. Singapore Management University, Singapore 178895, Singapore
随着智能手机的高速发展, Android内核变得越来越复杂, 可信计算基(trust computing base, 简称TCB)也越来越大.这使得Android内核会不可避免地存在一些已知的或未知的漏洞.攻击者可以利用这些漏洞来完全控制内核, 从而掌控整个Android系统来发起拦截短息, 盗取隐私信息(通讯录、照片)等攻击[1-3].这类攻击拥有内核权限且几乎不可能被用户察觉到, 危害极大.由于这类攻击的存在, Android内核这个绝大多数智能手机上的可信根不再可信.寻找权限更高的新的可信根来检测和抵御这类攻击的需求是非常迫切的, 而TrustZone就是新可信根的一个很好的选择[4-11].通过TrustZone来监控Android内核的运行, 是抵御内核级攻击、提高Android系统安全性的一种方法.
然而, TrustZone并不能主动地打断被监控操作系统的运行来进行实时的安全性检查, 通常需要依靠非安全世界操作系统的内核模块协助或者修改内核代码的方法来实现这一打断操作, 这些方法又会引入内核模块和被修改的代码的安全性问题.而处于非安全世界的Hypervisor可以利用硬件特性有效地拦截操作系统的系统调用、上下文切换和一些重要寄存器的访问等事件, 在监控点打断操作系统的运行.更重要的一点是, 在硬件虚拟化技术的帮助下, Hypervisor可以很好地保护自身空间来抵御内核级的攻击.HTrustZone利用Hypervisor的这些特点来协助TrustZone对非安全世界的操作系统进行实时的安全性检查.
1 硬件特性介绍 1.1 TrustZoneARM TrustZone技术作为安全拓展最早是在ARMv6的版本中被引入的[12], 它把硬件的资源划分为两个世界——非安全世界和安全世界, 其中, Android系统工作在非安全世界, TrustZone工作在安全世界.当CPU工作在安全世界模式时, 它可以访问安全世界的资源和非安全世界的资源.但是当CPU工作在非安全世界模式时, 安全世界的资源访问是被禁止的.例如, 当CPU工作在安全世界模式时, 通过操作TZASC(TrustZone address space contoller)寄存器和TZMA(TrustZone memory adapter)寄存器可以把一块物理内存设置为“安全内存(secure memory)”, 非安全世界对这块内存的访问将出现不可预知的错误.而安全世界是允许访问非安全世界的物理内存的.通过这种方式, 安全世界可以有效地保护特定的物理内存并监控非安全世界的物理内存的使用.正因为TrustZone拥有比工作在非安全世界的Android系统更高的权限, 它可以用来检测和监控Android系统的安全性.
图 1描述了ARMv7[13]的硬件架构, 非安全世界有3个模式:用户模式(USR mode)、内核模式(SVC mode)和HYP模式(HYP mode), 其中, 为了支持CPU的硬件虚拟化, ARMv7新增了HYP这个新的CPU模式.Android的应用程序运行在用户模式下, Android内核运行在内核模式下, Hypervisor运行在HYP模式下, 拥有非安全世界最高的权限.安全世界也有3个模式:用户模式、内核模式和监控模式(monitor mode).监控模式是连接非安全世界和安全世界的桥梁.在非安全世界的内核模式或者HYP模式下, 执行SMC(secure monitor call)指令, 可以主动地从非安全世界切换到安全世界的监控模式.在监控模式下执行ERET指令, CPU通过检查SCR(secure control register)寄存器的NS位来决定返回非安全世界还是继续停留在安全世界.监控模式拥有最高权限, 它可以访问CPU上的所有寄存器, 因此, TrustZone可以配置Hypervisor相关的控制寄存器来初始化并激活Hypervisor.
|
Fig. 1 ARMv7 architecture 图 1 ARMv7体系结构 |
1.2 Hypervisor
Hypervisor作为ARM的虚拟化拓展, 最早是在ARMv7的版本中被引入的[13].与TrustZone不同, Hypervisor运行在非安全世界最高权限模式下(HYP模式).在非安全世界, 应用程序运行在权限等级为0的模式下, 内核运行在权限等级为1的模式下, Hypervisor运行在权限等级为2的模式, 权限等级越高, 权限越大.因此, Hypervisor可以访问非安全世界包括寄存器、内存和Cache在内的所有硬件资源.在非安全世界的内核模式执行HVC (Hypervisor call)指令是进入Hypervisor的一种常见方式.
利用内存虚拟化技术, Hypervisor可以激活第2层内存地址翻译(Stage-2 translation)来管理内存.原本虚拟地址(VA)到物理地址(PA)的内存地址翻译就转变为虚拟地址(VA)到中间地址(IPA), 再从中间地址(IPA)到物理地址(PA)的内存地址翻译.其中, 第2层内存地址翻译(IPA到PA)的这个过程对于操作系统来说是透明的, 在操作系统看来, IPA就是它所看到的“物理地址”.通过设置第2层地址翻译页表项(page table descriptor)访问监控位, Hypervisor可以控制操作系统对内存物理页的访问属性.设置读写控制位, 可以把物理页的访问权限定义成只读、只写、读写和不可读不可写这4种类型.设置执行控制位, 可以把物理页的执行权限定义成可执行或不可执行.操作系统并不知道这种细粒度物理页访问监控的存在, 一旦操作系统违反了物理页的访问属性, CPU将产生异常陷入HYP模式, 并由Hypervisor去处理这个异常.利用第2层内存地址翻译, Hypervisor可以很好地保护自己的内存地址空间和监控操作系统对内存物理页的访问.不过, 一些外设(例如鼠标和键盘)可以通过DMA (direct memory access)的方式访问物理内存, 而DMA是不需要经过第2层内存地址的翻译的, 因此, Hypervisor不能直接控制DMA对物理内存的访问.在支持SMMU(system MMU, 与x86上的IOMMU类似)的设备上, 每一次DMA访问都需要IOVA到IOPA的翻译.检查并保护SMMU的页表, Hypervisor可以限制DMA物理内存访问的范围, 从而抵御DMA对敏感物理内存的攻击.
1.3 TrustZone与Hypervisor的优缺点分析● 所属世界:Hypervisor和被监控的操作系统都运行在非安全世界, 这有利于Hypervisor监控操作系统的各种硬件资源; 而TrustZone和被监控的操作系统运行在不同的世界, 有可能受到利用world gap的攻击.
● 拦截能力:Hypervisor拥有强大的拦截操作系统指令和事件的能力, 而TrustZone的拦截能力比较弱.
● 物理内存访问监控:Hypervisor拥有细粒度的物理内存访问监控能力; 而TrustZone无法做到物理内存的访问监控.
● 隔离能力:Hypervisor的隔离能力主要基于Staeg-2地址翻译对物理内存的隔离, 并需要解决DMA攻击的问题; 相比之下, TrustZone隔离能力更强大, 可以安全地隔离物理内存和外设, 隔离操作简单并且能完全抵御DMA攻击.
● 性能开销:Hypervisor只要打开Stage-2地址翻译, 就会给操作系统引入额外的性能开销; 而TrustZone则不存在额外性能开销的问题.
● 商业应用场景:目前还没有利用ARM硬件虚拟化(Hypervisor)技术来加固商用智能手机的产品; 而TrustZone作为比ARM硬件虚拟化技术出现更早的技术, 已经广泛地运用于商用智能手机中, 但它更多的是利用强大的隔离特性为商用智能手机提供安全服务(例如指纹解锁), 而监控商用智能手机操作系统的产品还相对较少, 因为TrustZone的监控能力较弱.
TrustZone的特点是隔离能力强、性能开销小和应用广; 而Hypervisor的特点是处于非安全世界、拦截能力强、灵活的内存访问监控.本文提出的HTrustZone把TrustZone和Hypervisor的特点结合到一起, 充分利用它们的硬件特性, 极大地强化了TrustZone的监控能力.
2 HTrustZone的设计虽然TrustZone拥有比非安全世界的Android系统更高的权限, 能够监控非安全世界操作系统的安全性, 但是从安全监控的角度来看, TrustZone存在3点不足.
1) World gap, TrustZone与被监控的Android系统之间存在world gap, 这使得TrustZone不能准确地获取非安全世界的信息;
2) 指令和事件的拦截能力薄弱;
3) 物理内存的访问监控能力薄弱.
HTrustZone利用工作在非安全世界Hypervisor的特性, 弥补了TrustZone的这3点不足.
图 2描述了HTrustZone的系统结构(虚线方框), 它横跨非安全世界和安全世界, 包含Hypervisor和TrustZone.非安全世界的Hypervisor工作在HYP模式下, 安全世界的TrustZone工作在监控模式下.工作在监控模式TrustZone在HTrustZone系统中占主导, 它可以动态地激活和关闭Hypervisor.这种设计的好处是:
|
Fig. 2 Architecture of HTrustZone 图 2 HTrustZone的架构 |
1) 消除了world gap, 因为HTrustZone既可以工作在非安全世界, 又可以工作在安全世界.
2) TrustZone可以借助Hypervisor的特性来提高自身监控能力:当需要监控时, 激活Hypervisor拦截Android系统的操作; 当监控任务完成后, 关闭Hypervisor以提高Android系统的整体性能.不过, 在监控能力增强的同时, HTrustZone也引入了两个安全性的问题:一是如何安全地启动HTrustZone, 即如何利用TrustZone安全地启动Hypervisor; 二是Hypervisor和TrustZone相互之间如何安全地切换.
2.1 启动HTrustZoneHTrustZone包含TrustZone和Hypervisor两个部分.TrustZone从系统上电之后就一直处于工作状态下; 而为了提高系统的整体性能, Hypervisor在需要协助TrustZone监控Android系统操作时才被激活.因此, 启动HTrustZone即利用TrustZone动态启动Hypervisor.
动态启动Hypervisor需要完成以下两个工作.
● 一是加载Hypervisor的代码到内存, 代码加载可由TrustZone或者Android内核来完成.前者具有更高的安全性, 因为TrustZone是可信的, 它存储和加载的操作也是可信的, 但这种方法加重了TrustZone的负担; 后者可以减轻TrustZone的负担, 但由于Android内核是不可信的, 它加载的操作也是不可信的, 需要TrustZone来对加载的代码的完整性进行验证.本文选择Android内核来加载Hypervisor的代码.
● 二是配置Hypervisor相关控制寄存器, 因为TrustZone可以访问Hypervisor的控制寄存器, 本文选择TrustZone直接操作Hypervisor的控制寄存器来初始化Hypervisor.
图 3描述了动态启动Hypervisor的步骤:首先, Android内核为Hypervisor分配内存(步骤1);接着, Android内核把Hypervisor的代码加载到所分配的内存的指定位置(步骤2);至此, 非安全世界的启动Hypervisor的准备工作完成.在步骤3中, 非安全世界发起SMC请求进入监控模式(TrustZone), 由TrustZone来初始化Hypervisor、保护步骤1分配的内存和验证步骤2加载的Hypervisor代码的完整性; TrustZone先往Android内核分配好的内存中填写Stage-2的页表数据(步骤4)并设置需要保护的物理页所对应页表项的属性; 然后, TrustZone初始化Hypervisor相关寄存器, 激活Stage-2地址翻译保护Android内核分配的内存(Hypervisor空间)和SMMU页表(步骤5);最后, 在步骤6中, 由于Hypervisor的代码和SMMU页表数据都是固定的, TrustZone分别计算它们的HMAC值, 再与正确的HMAC值比较, 以此来检查Hypervisor代码和SMMU页表数据的完整性.
|
Fig. 3 Steps of dynamical HTrustZone launch 图 3 动态启动HTrustZone的步骤 |
当这6个步骤完成并且完整性检查通过后, Hypervisor就被激活了, Android系统开始运行在虚拟机环境中. Stage-2地址翻译的机制确保了Hypervisor所使用的物理内存不会被不可信的Android内核恶意修改, Hypervisor自身的安全性得到了保障.当TrustZone需要监控Android系统运行或者检查Android系统运行状态时, 它可以借助Hypervisor去设置监控点和检查点, 以此提高监控能力.
2.2 TrustZone与Hypervisor的切换HTrustZone中, TrustZone工作在安全世界的监控模式下, Hypervisor工作在非安全世界的HYP模式下. TrustZone和Hypervisor之间切换的安全性直接影响到HTrustZone系统的安全性.通常, 进入TrustZone的方式是Android内核发起SMC请求; 而进入Hypervisor的方式是内核发起HVC请求或者内核的操作产生HYP异常陷入Hypervisor.
当CPU需要从Hypervisor的HYP模式切换到TrustZone的监控模式时, Hypervisor可以发起SMC请求直接进入监控模式.这个过程中, 不可信的Android内核无法介入, 不能打断或者干涉这个操作, 因此, 利用SMC请求从Hypervisor切换到TrustZone的过程是安全的.
当CPU需要从TrustZone的监控模式切换到Hypervisor的HYP模式时, 由于TrustZone不能像Android内核一样通过HVC请求直接进入Hypervisor, TrustZone需要通过其他方式切换到HYP模式, 方法有两种:第1种是先返回Android内核, 再从内核发起HYP请求进入Hypervisor; 第2种是修改返回地址和CPU状态相关寄存器, 直接返回到Hypervisor.显然, 第1种方法没有第2种方法安全, 因为第1种方法中, 不可信的Android内核参与了TrustZone切换到Hypervisor的过程, 攻击者可以在TrustZone返回Android内核与内核发起HYP请求的这个间隙发起对HTrustZone的攻击(例如跳过HVC请求); 而第2种方法的模式切换对Android内核来说是一个原子操作, 它没有办法干预, 本文采用第2种更为安全的切换方式.
3 HTrustZone的监控能力HTrustZone融合了TrustZone和Hypervisor这两者的硬件特性, 极大地增强了TrustZone监控Android系统的能力.
3.1 World GapTrustZone运行在安全世界, 而被监控的Android系统运行在非安全世界, 攻击者可以利用这个world gap发起一些特殊的攻击.CacheKit[14]是一个典型的利用world gap攻击的例子, 它利用Cache的不一致性, 即安全世界和非安全世界所使用的Cache line是完全隔离的, 把恶意代码隐藏在非安全世界的Cache中, 而非安全世界的Cache对TrustZone来说是透明的, 因此它无法察觉攻击者隐藏在非安全世界Cache中的恶意代码.World gap的存在, 从一定程度上限制了TrustZone对非安全世界的监控能力.
HTrustZone可以完全抵御world gap的攻击, 因为它横跨非安全世界和安全世界.当安全世界的TrustZone需要扫描非安全世界的Cache或者内存时, HTrustZone中的TrustZone可以动态地启动Hypervisor, 再安全地切换到Hypervisor的模式, 并由Hypervisor去扫描非安全世界的Cache或者内存.而Hypervisor和Android系统都处于非安全世界且Hypervisor拥有更高的权限, Android系统无法在Cache或者其他硬件中隐藏恶意代码, CacheKit的攻击很容易被检查到.
3.2 拦截能力TrustZone对非安全世界敏感事件(例如中断、系统调用)或者特殊指令拦截能力的强弱, 与其监控能力密切相关.而TrustZone的拦截能力主要体现在SCR寄存器的功能上.图 4是对SCR功能的描述[13], 从中可以看到, TrustZone的拦截能力很弱, 仅仅只能拦截非安全世界的各类中断(IRQ和FIQ)和外部错误(external abort), 这大大影响了TrustZone对非安全世界的监控能力.
|
Fig. 4 SCR register bit assignments 图 4 SCR寄存器的位说明 |
Hypervision[6]提出, 用TrustZone取代传统的操作系统内核去管理非安全世界的内存模块.TrustZone在为新的进程创建页表时, 会检查内核所在的物理内存的访问权限和执行权限, 检查是否存在多重页表映射等方式来保护物理内存.由于这些操作都是在TrustZone中完成的, 攻击者难以介入, 也难以绕过这些检查, 因此, 基于内存的很多内核攻击手段就失效了.Hypervision强化了运行时内核的保护, 实用高效, 被广泛地运用于三星公司生产的手机的Android内核中.但是, TrustZone薄弱的拦截能力导致它无法拦截内核操作页表控制寄存器的相关指令.在Hypervision的实现方案中, 内核中所有的操作页表控制寄存器的相关指令都被替换成了SMC指令, 这样, 每当这些指令需要执行的时候都会陷进TrustZone, TrustZone会检查这些指令相对应参数的准确性并模拟这些指令的执行.指令替换从一定程度上弥补了TrustZone拦截能力不足的缺陷, 然而这个方案存在3个缺点.
● 一是需要修改内核, 弱化了内核的兼容性和可移植性, 在不支持Hypervision的设备上, 系统就无法工作.当一个新的内核需要增加Hypervision的功能时, 修改内核并替换指令是必不可少的工作, 而且找出内核中所有的操作页表控制寄存器相关的指令也不是一件容易的事.
● 二是TrustZone需要识别出每个SMC指令所对应的页表控制寄存器操作指令.内核中原本可能就存在SMC指令, 当TrustZone收到内核SMC请求时, 首先它需要判断这是被替换之后的SMC指令, 还是内核中原本就存在的SMC指令, 再把替换的SMC指令解析成页表控制寄存器的操作指令, 这无疑增加了TrustZone的负担.
● 三是替换后的SMC指令安全性, 即如何保证这些指令不被不可信内核恶意修改和这些指令不被跳过, 需要额外的检查来保护SMC指令.
与TrustZone相比, Hypervisor拥有强大的拦截能力, HCR(HYP configuration register)描述了Hypervisor的拦截功能(如图 5所示).除了中断拦截功能之外, Hypervisor还可以通过配置HCR寄存器[13]拦截各类异常(包括系统调用)、拦截页表相关控制寄存器的操作指令、拦截TLB和Cache的操作等.对比图 4和图 5, 可以非常明显地看到HCR的功能比SCR丰富很多.
|
Fig. 5 HCR register bit assignments 图 5 HCR寄存器的位说明 |
HTrustZone拥有“SCR+HCR”的功能, 可以更友好地拦截Android系统的操作.HTrustZone可以利用HCR. TVM的功能来实现拦截页表控制寄存器的操作.当HCR.TVM位置为1, 页表控制寄存器操作将产生一个HYP的异常而陷入Hypervisor.Hypervisor可以发起SMC请求, 再由TrustZone中的Hypervision来处理这个操作. TrustZone处理完这个操作后, 如果直接执行ERET返回, 那么CPU模式又会切换回HYP模式, 最后由HYP模式返回内核, 继续执行内核的指令.但是这样的做法显得不够高效.本文的方案是, TrustZone在执行ERET返回之前, 修改spsr_mon和lr_mon寄存器直接返回到内核模式, 这样可以减少一次上下文的切换.由于HCR.TVM置1之后, 任何有效的页表控制寄存器的写操作都会陷入Hypervisor, 因此HTrustZone可以简单高效地拦截页表控制寄存器的操作, 避免了Hypervision实现过程中繁杂的指令替换操作.HTrustZone中的TrustZone可以识别出SMC请求是来自Hypervisor还是非安全世界的内核, 而且它能够识别触发异常指令的编码并解析出对应的页表控制寄存器操作指令, 这大大减轻了TrustZone的负担.HCR.TVM置1的拦截方式充分利用了硬件虚拟化技术的特点, 对于Android系统来说是透明的, 不存在指令替换方案中被攻击的问题.除此之外, HTrustZone也可以拦截非安全世界的系统调用、用户态和内核态的切换等事件.例如, 通过拦截系统调用, 解析binder数据传输, HTrustZone可以通过类似CopperDroid[15]的方法推测Android软件的行为.
3.3 物理内存访问的监控通过设置TZASC和TZMA寄存器, TrustZone可以把连续的几块物理内存设置为安全内存.而安全的物理内存是不允许非安全世界访问的, 即便是非安全世界以DMA的方式去访问安全内存也会产生不可预知的错误.因此, TrustZone可以实现对物理内存的隔离保护.但是它不能通过设置安全内存的方式来监控非安全世界对该内存的访问, 需要非安全世界操作系统的内核模块来协助监控内存的访问, 这种方式又引入了内核模块安全性的问题.而内存为系统的运行提供了代码和数据, 记录了当前系统的操作和行为.物理内存的访问监控也是TrustZone对非安全世界监控能力的一种直接体现.
HTrustZone拥有强大的物理内存访问监控能力.正如第1节所提到的, Hypervisor激活Stage-2页表翻译机制之后, 可以支持页粒度物理内存的访问监控.HTrustZone的TrustZone可以借助Hypervisor这一特性实现物理内存的访问监控.不仅如此, Hypervisor还可以通过配置debug寄存器来实现指令级物理地址的访问监控.不过, ARM设备上的debug寄存器数目相对有限, 同一时间能够指定的物理地址数目也是有限的(例如, Raspberry Pi2上debug寄存器的数目是8个).Hypervisor中, 这些监控物理内存访问的设置对于非安全世界的操作系统来说也是透明的.
当HTrustZone中的TrustZone需要监控Android系统对物理内存的访问时, 它可以动态启动Hypervisor并在Stage-2页表项上设置好需要监控的物理页的属性.当Android系统违反访问物理页面访问属性时, 会产生Stage-2的页错误(page fault)异常直接陷进Hypervisor.在页错误的的处理函数中, Hypervisor执行SMC指令进入监控模式, 让TrustZone来处理这个异常.
通过配置debug的相关寄存器, TrustZone可以让debug异常直接陷进Hypervisor.当debug的目标地址被访问时, 产生的debug异常将陷进Hypervisor.同样地, 在Hypervisor的异常处理函数中, 执行SMC指令进入监控模式, 由TrustZone来处理debug异常.在ARM的架构中, 异常向量表作为内核的入口通常是在固定的虚拟地址上, 系统调用的入口位于偏移为0x8的位置, 中断的入口位于偏移为0x14(IRQ)和0x18(FIQ)的位置.如果把debug寄存器设置为系统调用入口的虚拟地址, 那么TrustZone可以拦截所有的系统调用; 如果两个中断入口的虚拟地址都设置断点, 那么TrustZone可以拦截所有的中断.
4 系统实现我们在Raspberry Pi2开发板[16]上实现了HTrustZone原型系统.在Raspberry Pi2开发板上, Android5.1运行在非安全世界的用户模式和内核模式下.HTrustZone包含Hypervisor和TrustZone两部分, 其中, Hypervisor运行在非安全世界的HYP模式, TrustZone运行在安全世界的监控模式下.HTrustZone原型系统的实现主要包含3部分内容:启动HTrustZone、HYP模式和监控模式的相互转换和Hypervisor的拦截功能.本节将介绍这3部分的实现细节.
4.1 启动HTrustZone在第2.1节中, 本文提出了启动HTrustZone的方法, 其核心内容是TrustZone动态启动Hypervisor.
首先, Android内核为Hypervisor分配内存, 用来加载Hypervisor的代码、分配Hypervisor栈和存储Stage-2页表数据.Hypervisor代码的加载是由Android内核来完成的, 而栈分配和页表数据的填写由TrustZone来完成.
因为在动态启动Hypervisor之后仍然需要保证Android系统的正常运行, 所以Stage-2页表管理的中间地址(IPA)到物理地址的映射必须是一一映射, 以维持虚拟地址依然能够映射到正确的物理地址.Stage-2的页表采用3级长描述型页表(long-descriptor translation format)[13].由于Android内核所能分配的最大的连续内存大小是4M, 考虑到Stage-2页表数据大小, 内核需要为Hypervisor分配3块连续的4M内存.如图 6所示, 内存的布局为:第1块内存存放第1级和第2级Stage-2的页表数据, Android内核可以把Hypervisor的代码也加载到第1块内存中, 剩下的内存可以作为Hypervisor运行时的栈来使用; 第2块和第3块内存存放第3级Stage-2的也表数据.虽然Raspberry Pi2的内存大小是1G, 但由于IO内存的存在, 最高的物理地址远大于0x40000000, 为了确保所有的中间地址(IPA)都有映射, 我们映射了4G的IPA地址空间.因此, 第3级Stage-2的页表数据大小是8M.
|
Fig. 6 Hypervisor memory layout 图 6 Hypervisor的内存布局 |
当Android内核为Hypervisor分配好内存之后, 执行SMC指令通知TrustZone初始化Hypervisor.TrustZone先根据Android内核所分配内存的物理地址填写Stage-2的3级页表数据到对应的物理内存位置.接着初始化Hypervisor相关控制寄存器[13], 并通过配置VTCR(virtualization translation control register), VTTBR (virtualization translation table base register), HVBAR(HYP vectors base address register)和HCR寄存器激活Stage-2地址翻译, 设置Stage-2的页表项来保护Hypervisor的空间(Android内核分配的12M内存).由于Raspberry Pi2硬件上不支持SMMU, 因此Hypervisor需要其他方式来抵御DMA攻击(例如拦截IO操作、检查DMA操作).最后, TrustZone计算Hypervisor代码的HMAC值来检查代码和数据的完整性.如果检查通过了, TrustZone可以选择返回Android内核, 也可以选择返回到HYP模式来执行Hypervisor的代码.至此, 动态启动Hypervisor的工作就完成了, HTrustZone开始工作.
4.2 TrustZone与Hypervisor的切换当HTrustZone工作时, TrustZone和Hypervisor之间的相互切换是必不可少的.例如在CacheKit的检测方案中, TrustZone需要从监控模式切换到Hypervisor的HYP模式来扫描内存和Cache中是否存在恶意代码.在ARMv7中, 当Android内核执行SMC指令的时候, CPU的模式由非安全世界的内核模式切换到安全世界的监控模式, CPSR(current program status register)寄存器备份在spsr_mon寄存器中, 返回地址(SMC的下一条指令)保存在lr_mon寄存器中.当在监控模式下, 执行ERET指令返回时, CPSR从spsr_mon寄存器中恢复, 其中, CPSR.M[4:0]表示当前CPU的工作模式.由于SMC指令是从Android内核发起, 因此CPSR.M被恢复成非安全世界内核模式.PC寄存器指向lr_mon寄存器中保存的地址.为了实现从TrustZone返回HYP模式, 需要备份spsr_mon寄存器并把spsr_mon.M[4:0]的内核模式修改为HYP模式, 再备份lr_mon寄存器并把lr_mon修改成Hypervisor对应扫描内存的函数入口地址, 然后再执行ERET指令.Hypervisor响应完TrustZone的请求之后, 把备份的spsr_mon和lr_mon寄存器恢复到到spsr_hyp和elr_hyp寄存器中, 执行ERET指令返回到内核模式继续执行内核的指令.
图 7是对这个过程的小结:(1)内核执行SMC指令进入监控模式; (2)监控模式下修改spsr_mon和lr_mon寄存器返回HYP模式; (3) HYP模式下修改spsr_hyp和elr_hyp寄存器回到内核模式.
|
Fig. 7 Context swith from monitor mode to HYP mode 图 7 从监控模式到HYP模式的上下文切换 |
在HTrustZone中, 从Hypervisor切换到TrustZone也是非常常见的.例如Hypervision的优化方案和物理内存的访问监控, Hypervisor需要先拦截特殊指令的执行或者物理内存访问的事件, 再从HYP模式切换到监控模式, 进入TrustZone, 并由TrustZone去进行相应的处理.HTrustZone在初始化Hypervisor时, 激活特殊指令的和物理内存访问事件的拦截功能, 一旦Android内核执行特殊指令或者违反物理内存的访问规则, 则CPU将陷入HYP模式.而在HTrustZone中, Hypervisor的功能是辅助TrustZone拦截Android内核的操作, 因此, Hypervisor在处理函数中, 执行SMC指令进TrustZone, 同时把备份的spsr_hyp寄存器的值和elr_hyp寄存器的值保存到通用寄存器中.通过HSR(HYP syndrome register)寄存器, TrustZone能够解析出Hypervisor所拦截的事件是对指令的监控还是对物理内存访问的监控.如果是指令监控, TrustZone解析出该指令并模拟指令的执行.如果与物理内存的访问监控相关, 通过HDFAR(HYP data fault address registr)寄存器, TrustZone能够得到内存放问的目标地址, 从而采取相对应的处理.当TrustZone处理完成后, 把spsr_mon和lr_mon分别修改成保存的spsr_hyp和elr_hyp的值, 执行ERET指令回到Android内核继续执行其他指令.
图 8是对这个过程的小结:(1) Hypervisor拦截内核事件或者指令; (2) Hypervisor执行SMC指令进入监控模式; (3)监控模式下修改spsr_mon和lr_mon寄存器回到内核模式.
|
Fig. 8 Context switch from HYP mode to monitor mode 图 8 从HYP模式到监控模式的上下文切换 |
4.3 HTrustZone的拦截能力
在第2.2节中, 我们比较了TrustZone和Hypervisor的拦截能力, 发现Hypervisor拥有比TrustZone更为强大的拦截能力, 因此, HTrustZone的拦截能力主要体现在Hypervisor上, 而Hypervisor拦截Android内核操作的方法主要有3种:(1)设置HCR寄存器的相关功能位; (2)设置Stage-2页表项的物理页访问属性; (3)设置debug寄存器.TrustZone可以访问相关寄存器和Stage-2所在物理页的页表数据来激活这3种拦截功能.
● 设置HCR寄存器
图 3介绍了HCR寄存器的每一位, 从中可以看到, HCR寄存器的功能非常丰富.例如, HCR.TGE置1可以拦截用户模式到内核模式的切换; HCR.TVM置1可以拦截页表相关控制寄存器的操作; HCR.TTLB置1可以拦截TLB的操作; HCR.TSC置1可以拦截SMC指令的执行, 等等.不过, HCR寄存器往往针对的是拦截一类事件, 一但某个拦截功能被打开, Android内核会频繁地陷进HYP模式, 其中可能会引入大量的噪音, 因此, Hypervisor或者TrustZone需要从中过滤出真正需要拦截的事件.
● 设置Stage-2页表项
Stage-2地址翻译的页表项包含读、写、执行这3个物理内存访问属性位, 设置第3级页表项的这3个属性位, 可以实现页粒度的物理内存读、写、执行的访问监控.页表项的第6位和第7位为读写位, 第54位为执行位.由于我们设计的Stage-2页表映射是一一映射, 因此, 物理页的地址与该页所对应的第3级页表项的地址是线性关系.当TrustZone需要监控或者保护某个物理页的时候, 根据物理页的地址即可方便地定位到对应页表项所在的地址, 并根据监控或者保护的需求设置3个属性位.一旦Android内核违反物理页访问规则, 系统将产生Stage-2的page fault而陷进Hypervisor.此时, 如果是Android内核的正常操作触发了page fault, Hypervisor或者TrustZone不能在物理页访问属性未修改的情况下返回到触发page fault的指令, 因为这样的操作会再一次触发page fault而出现死循环.Hypervisor或者TrustZone的处理方式有两类:(1)修改物理页访问属性并返回(适合一次监控); (2)不修改物理页访问属性模拟执行或者跳过触发page fault的指令返回到下一条内核指令(适合永久监控).这样, HTrustZone可以实现细粒度的物理内存监控和保护.
● 设置debug寄存器
在敏感指令或者数据上设置断点的方法可以提供指令级的物理内存访问监控.通常情况下, 设置DGBBCR (breakpoint control register)和DBGBVR(breakpoint value register)这两个寄存器可以在Android内核指令上设置断点.当CPU读取该指令的时候, 断点将触发并产生一个异常陷入到内核的异常处理函数中.但是当HDCR (HYP debug configuration register)的TDE位被置1时, 该异常会直接陷入HYP模式.同时, HDCR.TDA置1可以防止Android内核修改DGBBCR和DBGBVR的配置以保证断点的有效性和断点地址不被修改.当TrustZone需要监控内核的某个指令的时候, 可以通过配置debug寄存器, 借助Hypervisor的拦截功能来实现.
5 实验结果在Raspberry Pi2开发板上, 我们对HTrustZone系统运行的性能进行了测试.Raspberry Pi2是ARMv7架构下的开发板, 它搭载了4个Cortex-A7 CPU和1GB的内存, 其中, CPU的主频是900MHz.运行在Raspberry Pi2开发板非安全世界的操作系统是Android 5.1 Lollipop, 内核版本为4.1.3.HTrustZone框架系统的可信计算基非常小, 一共仅包含142行汇编码和248行C代码, 其中, Hypervisor包含63行汇编码, TrustZone包含79行汇编码和248行C代码.Hypervisor和TrustZone自身代码的安全性可以通过形式化验证的方法来保证.HTrustZone框架系统只包含动态启动Hypervisor和Hypervisor与TrustZone之间相互切换这两部分功能, 不包含TrustZone对监控事件检查和处理的功能.而HTrustZone框架系统是可扩展的, 可以根据需求在HTrustZone中设置监控点并添加相应的处理功能.我们测试了HTrustZone系统启动所需要的时间、上下文切换的时间和虚拟化环境下Android系统的整体性能, 并与传统的TrustZone监控方法做了比较.
5.1 HTrustZone启动通常, TrustZone的初始化是在系统启动阶段、Android内核初始化之前完成的[17-19], 在我们的实验环境中也是如此.而HTrustZone是在运行时(run-time)启动的, 引入了额外的运行时启动的性能开销.HTrustZone系统的启动主要包含4个步骤:(1) Android内核发起SMC请求, 切换上下文; (2) TrustZone准备Stage-2页表数据; (3) TrustZone计算Hypervisor代码的HMAC值, 检查代码完整性; (4) TrustZone初始化Hypervisor完成并返回Android内核.其中, 主要的时间消耗是在第2步和第3步.从表 1中我们可以看到, HTrustZone的一次启动时间(从发起SMC请求到返回SMC的下一条指令)是18.064ms, 时间很短, 对用户来说几乎感觉不到.TrustZone往内存中填写超过8M的3级Stage-2页表数据需要14.498ms, 计算Hypervisor代码HMAC值需要的时间是3.451ms, 而这两者的时间之和与HTrustZone启动的总时间已经十分接近.
|
Table 1 HTrustZone lauch lantency (ms) 表 1 HTrustZone启动时间 (毫秒) |
5.2 上下文切换
在传统的仅仅依赖TrustZone监控非安全世界操作系统运行的模式中, 只有1种上下文切换的模式, 即非安全世界内核模式与安全世界监控模式之间的切换.通常, 从非安全世界切换到TrustZone是通过SMC调用实现的[6-8, 20], 因此, 监控的开销只是一次SMC调用, 即247.4ns(见表 2).
|
|
Table 2 Context switch latencies (ns) 表 2 上下文切换时间 (纳秒) |
相比之下, HTrustZone系统涉及到多个上下文切换, 包括简单的切换和复杂的切换.其中, 简单的切换是指非安全世界的内核模式和HYP模式的切换(HVC指令)、非安全世界和安全世界的切换(SMC指令), 我们测试了一次空的HVC调用和SMC调用所需要的时间; 复杂的切换是指Android内核模式调用SMC指令切换到安全世界监控模式, 监控模式返回非安全世界HYP模式, 最后由HYP模式回到Android内核模式和Android内核模式调用HYP指令切换到HYP模式, HYP模式再调用SMC指令进入安全世界监控模式, 最后由监控模式返回到Android内核.表 2中, “HVC调用”测试的是从Android内核发起一次HVC调用开始到HVC调用返回到Android内核所需要的时间, 这里包含两次上下文切换; “SMC调用”测试的是从Android内核发起一次SMC调用开始到SMC调用返回到Android内核所需要的时间, 它也包含两次上下文切换(world switch); “内核_监控_HYP_内核”测试的是从Android内核模式发起一次SMC调用进入监控模式, 监控模式修改相关寄存器返回HYP模式, 最后由HYP模式通过修改相关寄存器返回内核模式所需要的时间, 这里存在3次上下文切换; “内核_HYP_监控_内核”测试的是从Android内核模式发起一次HYP调用进入HYP模式, HYP模式再发起SMC调用进入监控模式, 最后由监控模式通过修改相关寄存器返回内核模式所需要的时间, 它也包含3次上下文切换.
从表 2中可以看到, 在Raspberry Pi2开发板上, 一次HVC调用所需要的时间是39.2ns, 而一次SMC调用所需要的时间则是247.4ns, 一次SMC调用所需要的时间是一次HVC调用所需要时间的近10倍.其中的原因是, HVC调用只是在非安全世界下两个不同的CPU模式之间的切换; 而SMC调用不仅是在CPU不同模式之间的切换, 而且是在两个不同世界的切换(world switch), 会涉及更多硬件处理.
在HTrustZone中, 由于TrustZone需要借助Hypervisor的功能增强监控能力, 原本仅仅依赖SMC调用进行的上下文切换将变成“内核_监控_HYP_内核”或“内核_HYP_监控_内核”这两种模式的切换.在监控功能增强的同时也引入了额外的开销, 但相对于SMC调用, “内核_监控_HYP_内核”的额外开销是58.7ns, 而“内核_监控_HYP_内核”的额外开销是60.0ns.额外开销都很小, 这主要得益于HVC调用比SMC调用快得多.
5.3 Android系统的整体性能当ARM平台上只有非安全世界的Android系统在工作时, 内存地址只需要进行一层翻译(虚拟地址到物理地址); 而当Android系统和安全世界的TrustZone同时在ARM平台工作的时候, 由于这两者运行在不同的世界, 彼此之间完全隔离, 在Android系统不发起SMC调用和TrustZone不主动打断Android系统运行的情况下, Android系统仍可以保持原有的系统性能, 即TrustZone的运行不会给Android系统带来额外的性能开销.但当HTrustZone工作时, Hypervisor被激活, 为保护它自身的空间, Stage-2地址翻译被打开.这对Android系统来说, 原本虚拟地址到物理地址的一层内存地址翻译就变成了虚拟地址到中间地址(IPA)再到物理地址的两层内存地址翻译, 额外的性能开销(Stage-2地址翻译)就被引入了.我们在Hypervisor未被激活和Hypervisor激活两种状态下, 在Raspberry Pi2开发板运行Vellamo和CF-bench两个benchmark来测试Android系统的整体性能.
表 3记录了在Hypervisor未激活(TrustZone)和激活(HTrustZone)状态下, Android系统运行两个benchmark的得分, 得分越高性能越好.其中, Vellamo的Multicore测试项测试的是浮点运算、内存读写、系统调用和并行计算的系统性能, Metal项测试的是CPU和网络的性能, CF-bench测试的是内存读写和磁盘读写分别在本地和Dalvik虚拟机中的性能, 并在最后给出了总体的性能.
|
|
Table 3 Benchmark scores 表 3 Benchmark结果 |
从表中的数据我们可以看到, Hypervisor激活状态下, Stage-2地址翻译的额外开销为(0.0%~3.6%)几乎可以忽略不计.如果只从地址翻译的角度考, 理论上2层地址翻译的开销应该是1层地址翻译开销的2倍.但由于TLB(translation looksides buffer)的存在, 使得Stage-2地址翻译的开销大为降低, 因为并不是每一次地址翻译都要去走2层MMU, 绝大多数情况都可以直接从TLB缓存中命中.
5.4 HTrustZone与TrustZone监控能力的比较现有的TrustZone的监控系统[6-8, 20]都只工作在安全世界, 无法抵御world gap的攻击; 对于指令的拦截, 通常需要用SMC指令替换所要拦截的指令; 而且只能实现物理内存的隔离, 无法实现物理内存的访问监控.而HTrustZone结合了TrustZone和Hypervisor的硬件特性, 可以有效地抵御world gap的攻击; 借助Hypervisor的拦截功能可以实现对控制指令的拦截; 激活Stage-2地址翻译为需要监控的物理内存设置访问属性, HTrustZone能够监控Android系统对物理内存的访问.表 4对比了HTrustZone和TrustZone的监控能力, HTrustZone在对Android系统的监控能力上具有比TrustZone明显的优势.
|
|
Table 4 Introspection capability comparisons between HTrustZone and TrustZone 表 4 HTrustZone与TrustZone监控能力的比较 |
6 相关工作 6.1 TrustZone监控系统
在ARM平台上, 已有多种基于TrustZone的监控系统被提出来解决数据安全性审查、内核代码完整性加固、运行时内核代码保护等问题.Jang等人提出了利用TrustZone来检查非安全世界操作系统的数据安全性[20]. Ge等人提出的SPROBES[7]利用TrustZone维护5条内核安全属性, 以此来保护操作系统内核代码的完整性. Azab等人提出的Hypervision[6]在运行时对内核代码进行保护, 它是三星KNOX技术的核心[8, 17].这些监控系统利用TrustZone安全的执行环境和高权限, 可以有效地检查数据的安全性和代码的完整性.但是, 它们都需要修改操作系统内核, 并在监控点添加SMC指令或者向内核添加一个内核模块以确保TrustZone可以在监控点处对操作系统进行安全性检查.这样的解决方案又引入了如何保证SMC指令不被跳过和如何保护内核模块的安全问题.而HTrustZone监控系统不需要修改操作系统的内核就可以实现监控的功能, 它可以通过指令拦截、在Stage-2页表项上设置物理内存访问属性、设置debug寄存器等多种方式自由地设置监控点, 并且这些监控点对于操作系统是透明的, 因此操作系统无法修改或绕过这些监控点.利用Stage-2地址翻译, HTrustZone可以有效地保护非安全世界的Hypervisor空间的安全性.
6.2 动态启动Hypervisor在文献[18]中, Cho等人提出了一种动态启动Hypervisor的方法:他们在内存高地址中预留了128M空间存放Hyperviosr的代码和数据, 当Hypervisor没有被激活的时候, 这段内存被设置为安全内存以访问不可信内核的恶意修改; 当Hypervisor被激活时, 这段内存就被设置为非安全世界的非安全内存并受到Stage-2地址翻译的保护.Android内核可以通过执行SMC指令进入TrustZone, 并由初始化Hypervisor的相关寄存器, 打开Staeg-2地址翻译, 动态修改这128M物理地址的属性为非安全世界的物理内存, 以保证Hypervisor的代码能顺利地在非安全世界执行.这种动态启动Hypervisor方法存在两点不足:一是在Hypervisor激活状态和非激活状态下, Android内核都不能使用预留的内存空间, 降低了内存的利用率; 二是TrustZone不仅需要初始化Hypervisor, 还需要把Hypervisor的代码和数据加载到预留的内存中, 这无疑增加了TrustZone的负担.而本文和文献[21]中所采用的动态启动Hypervisor的方法借助Android内核动态内存管理的功能, 并由Android内核加载Hypervisor的代码和数据.由于Android内核是不可信的, 它所加载的Hypervisor的代码和数据必须经过TrustZone的验证以保证动态启动的安全性.相对于Cho等人的方法, 本文的方法提高了内存的利用率, 简化了TrustZone的工作.
6.3 Intel SGX技术TrustZone技术为运行在ARM平台上的操作系统提供了可信的隔离环境, 可以抵御来自隔离环境外部的攻击.在Intel平台上, SGX(software guard extensions)技术为开发者提供了一个可信的执行环境(enclave), 通过特殊的指令, 开发者可以把指定的代码放到Enclave中来运行.SGX技术保证在Enclave外部的程序无法访问Enclave内部的代码和数据, 即便是该程序拥有高权限(内核权限或者Hypervisor权限)[22].TrustZone技术和SGX技术的共同点是都提供了可抵御内核或者更高级别攻击的可信执行环境, 不同点是, TrustZone技术引入了新的CPU运行模式, 通过控制寄存器的设置把硬件资源划分为两部分——secure和non-secure, TrustZone和Rich OS分别运行在两个世界, 相互独立; 而SGX技术并没有引入新的CPU运行模式, 而是借助内核动态地创建Enclave的执行环境, 当用户态的程序执行特殊指令时, 就会进入Enclave执行Enclave内部的代码.开发者可以非常自由地把敏感的代码放到Enclave中去执行, 这是TrustZone无法做到的.Enclave和Rich OS更像是捆绑在一起的关系, 而不是像TrustZone那样相互独立, 因此, 利用SGX技术可以更加方便和有效地介入和监控Rich OS的运行.与此同时, 和Rich OS密切的联系也为Enclave埋下了容易受到侧信道(side-channel)攻击的隐患, 如基于page fault[23, 24]和基于cache的侧信道攻击.
6.4 Hypervisor, TrustZone的安全性ARM的虚拟化扩展和安全扩展从硬件上为Hypervisor和TrustZone提供了安全支持, 极大地增加了从用户态或者内核态对Hypervisor或TrustZone进行攻击的难度.目前, 主流的从外部攻击Hypervisor和TrustZone的方法是通过侧信道[25, 26].然而, Hypervisor或者TrustZone侧信道信息的获取并没有像获取Enclave内部侧信道信息那么容易, 因此在Hypervisor或者TrustZone进行侧信道攻击虽然是可行的, 但难度非常大.攻击者更多的是选择从Hypervisor和TrustZone内部来进行攻击.随着Hypervisor和TrustZone的功能复杂化, 相应的代码量也快速增加, 代码中的漏洞就不可避免地出现了[27-29].攻击者正是利用这些漏洞获取系统的高权限并完成相应的攻击.这类攻击的防护是非常困难的, 比较有效的防护措施是对Hypervisor和TrustZone的代码做形式化验证, 但目前, 形式化验证技术只适用于代码量较小的系统或软件, 而商用Hypervisor和TrustZone的代码量非常庞大.
由于ARM平台上的Hypervisor并没有得到广泛得运用, 而主流的ARM设备都是支持虚拟化(支持Hypervisor)的, 这些支持Hypervisor却没有激活Hypervisor的设备可能会受到一类新型的攻击, 那就是攻击者可以利用内核漏洞动态地启动一个恶意的Hypervisor并发起类似VMI(virtual machine introspection)形式的攻击.
7 结束语本文结合ARM硬件虚拟化特性和TrustZone技术特性, 提出了一种可扩展框架系统HTrustZone, 能够借助Hypervisor提高TrustZone监控能力, 解决了HTrustZone安全启动、Hypervisor与TrustZone之间安全切换的问题.相对于传统的TrustZone监控系统, HTrustZone系统拥有更为丰富的监控方式和更强大的监控能力, 可以为被监控的操作系统提供更好的安全性支持.实验结果也表明, HTrustZone框架系统在系统启动、上下文切换和操作系统整体性能上的额外开销是可接受的.
| [1] |
Xu W, Li J, Shu J, Yang W, Xie T, Zhang Y, Gu D. From collision to exploitation: Unleashing use-after-free vulnerabilities in linux kernel. In: Proc. of the 22nd ACM Conf. on Computer and Communications Security (CCS 2015). 2015.http://dl.acm.org/citation.cfm?id=2813637 |
| [2] |
Zhou Y, Jiang X. Dissecting android malware: Characterization and evolution. In: Proc. of the 2012 IEEE Symp. on Security and Privacy (S&P 2012). 2012.http://ieeexplore.ieee.org/document/6234407/ |
| [3] |
Artenstein N, Revivo I. Man in the binder: He who controls IPC, controls the Droid. Black Hat Europe, 2014. |
| [4] |
Li W, Li H, Chen H, Xia Y. Adattester: Secure online mobile advertisement attestation using trustzone. In: Proc. of the 13th Annual Int'l Conf. on Mobile Systems, Applications, and Services (MobiSys 2015). 2015.https://www.researchgate.net/publication/280571153_AdAttester_Secure_Online_Mobile_Advertisement_Attestation_Using_TrustZone |
| [5] |
Sun H, Sun K, Wang Y, Jing J, Jajodia S. Trustdump: Reliable memory acquisition on smartphones. In: Proc. of the Computer Security-ESORICS. 2014.https://link.springer.com/chapter/10.1007/978-3-319-11203-9_12 |
| [6] |
Azab AM, Ning P, Shah J, Chen Q, Bhutkar R, Ganesh G, Ma J, Shen W. Hypervision across worlds: Real-Time kernel protection from the arm trustzone secure world. In: Proc. of the 21st ACM Conf. on Computer and Communications Security (CCS 2014). 2014. |
| [7] |
Ge X, Vijayakumar H, Jaeger T. SPROBES: Enforcing kernel code integrity on the trustzone architecture. In: Proc. of the 2014 Mobile Security Technologies (MoST) Workshop. 2014.https://www.researchgate.net/publication/267515544_Sprobes_Enforcing_Kernel_Code_Integrity_on_the_TrustZone_Architecture |
| [8] |
Samsung. White Paper: An Overview of Samsung KNOX. 2013. |
| [9] |
Jang J, Kong S, Kim M, Kim D, Kang BB. Ssecret: Secure channel between rich execution environment and trusted execution environment. In: Proc. of the 22nd Annual Network and Distributed System Security Symp. (NDSS 2015). 2015.https://www.researchgate.net/publication/293012244_SeCReT_Secure_Channel_between_Rich_Execution_Environment_and_Trusted_Execution_Environment |
| [10] |
Sun H, Sun K, Wang Y, Jing J. Trustotp: Transforming smartphones into secure one-time password tokens. In: Proc. of the 22nd ACM Conf. on Computer and Communications Security (CCS 2015). 2015.http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.720.5973 |
| [11] |
Guan L, Liu P, Xing X, Ge X, Zhang S, Yu M, Jaeger T. TrustShadow: Secure execution of unmodified applications with ARM TrustZone. In: Proc. of the 15th Annual Int'l Conf. on Mobile Systems, Applications, and Services (MobiSys 2017). 2017.https://doi.acm.org/10.1145/3081333.3081349 |
| [12] |
ARM. ARMv6-m architecture reference manual. Technical Report, ARM DDI 0419C (ID092410), ARM, 2007.http://infocenter.arm.com/help/topic/com.arm.doc.ddi0419c/ |
| [13] |
ARM. Architecture reference manual ARMv7-a and ARMv7-r edition. Technical Report, ARM DDI 0406C. c (ID051414), ARM, 2014.http://infocenter.arm.com/help/topic/com.arm.doc.ddi0406c/index.html |
| [14] |
Zhang N, Sun H, Sun K, Lou W, Hou Y. Cachekit: Evading memory introspection using cache incoherence. In: Proc. of the 2016 IEEE European Symp. on Security and Privacy (Euro S&P 2016). 2016.http://ieeexplore.ieee.org/document/7467364/ |
| [15] |
Tam K, Khan SJ, Fattori A, Cavallaro L. CopperDroid: Automatic reconstruction of Android malware behaviors. In: Proc. of the 22nd Annual Network and Distributed System Security Symp. (NDSS 2015). 2015.https://www.researchgate.net/publication/300925104_CopperDroid_Automatic_Reconstruction_of_Android_Malware_Behaviors |
| [16] |
Raspberry Pi2 development board. https://www.raspberrypi.org/products/raspberry-pi-2-model-b/ |
| [17] |
Kanonov U, Wool A. Secure containers in Android: The Samsung KNOX case study. In: Proc. of the Workshop on Security and Privacy in Smartphones and Mobile Devices (SPSM 2016). 2016.http://dl.acm.org/citation.cfm?id=2994470 |
| [18] |
Cho Y, Shin J, Kwon D, Ham MJ, Kim Y, Paek Y. Hardware-Assisted on-demand hypervisor activation for efficient security critical code execution on mobile devices. In: Proc. of the USENIX ATC. 2016.https://usenix2016.sched.com/overview/type/ATC+%2716/Paper+Presentation |
| [19] |
Sun H, Sun K, Wang Y, Jing J, Wang H. TrustICE: Hardware-Assisted isolated computing environments on mobile devices. In: Proc. of the 45th Annual IEEE/IFIP Int'l Conf. on Dependable Systems and Networks (DSN 2015). 2015.http://dl.acm.org/citation.cfm?id=2859948 |
| [20] |
Williams J. Inspecting Data from Safety of Your Trusted Execution Environment. Black Hat USA, 2015. |
| [21] |
Zhang Z, Ding X, Tsudik G, Cui J, Li Z. Presence attestation: The missing link in dynamic trust bootstrapping. In: Proc. of the 24th ACM Conf. on Computer and Communications Security (CCS 2017). 2017.http://dl.acm.org/citation.cfm?id=3134094 |
| [22] |
Intel. Intel software guard extensions programming reference (rev2). Technical Report, Intel Corporation, 2014. |
| [23] |
Shih M, Lee S, Kim T, Peinado M. T-SGX: Eradicating controlled-channel attacks against enclave programs. In: Proc. of the 24th Annual Network and Distributed System Security Symp. (NDSS 2017). 2017.https://www.researchgate.net/publication/316913423_T-SGX_Eradicating_Controlled-Channel_Attacks_Against_Enclave_Programs |
| [24] |
Wang W, Chen G, Pan X, Zhang Y, Wang X, Bindschaedler V, Tang H, Gunter C. Leaky cauldron on the dark land: understanding memory side-channel hazards in SGX. In: Proc. of the 24th ACM Conf. on Computer and Communications Security (CCS 2017). 2017.http://dl.acm.org/citation.cfm?id=3134038 |
| [25] |
Shahzad A, Litchfield A. Virtualization technology: Cross-VM cache side channel attacks make it vulnerable. In: Proc. of the Australasian Conf. on Information Systems. 2015.http://www.researchgate.net/publication/303821673_Virtualization_Technology_Cross-VM_Cache_Side_Channel_Attacks_make_it_Vulnerable |
| [26] |
Zhang N, Sun K, Shands D, Lou W, Hou Y. TruSpy: Cache side-channel information leakage from the secure world on ARM devices. In: Proc. of the Cryptology ePrint Archive 2016. 2016.https://eprint.iacr.org/2016/980 |
| [27] |
Baumann A, Peinado M, Hunt G. Shielding applications from an untrusted cloud with haven. ACM Trans. on Computer Systems, 2014, 33(3): 1–26.
https://www.usenix.org/node/186174 |
| [28] |
Zhang F, Chen J, Chen H, Zhang B. Cloudvisor: Retrofitting protection of virtual machines in multi-tenant cloud with nested virtualization. In: Proc. of the 23rd ACM Symp. on Operating System Principles. 2011.https://www.researchgate.net/publication/220910130_CloudVisor_Retrofitting_protection_of_virtual_machines_in_multi-tenant_cloud_with_nested_virtualization |
| [29] |
Machiry A, Gustafson E, Spensky C, Salls C, Stephens N, Wang R, Bianchi A, Choe Y, Kruegel C, Vigna G. BOOMERANG: Exploiting the semantic gap in trusted execution environments. In: Proc. of the 24th Annual Network and Distributed System Security Symp. (NDSS 2017). 2017.https://www.osti.gov/biblio/1415101-boomerang-exploiting-semantic-gap-trusted-execution-environments |