利用TrustZone保护可信程序免受恶意操作系统攻击

文/管乐

利用TrustZone保护可信程序免受恶意操作系统攻击

文/管乐

IoT（物联网）设备正在疯狂渗透人们的生活。从IP摄像头，外科手术机器人， 语音智能辅助系统，到边缘计算（如智能路由器），人们的生活工作环境已经由上亿个IoT设备互联。不如此，这些设备需要有足够的智能来协助我们来处理事务，比如，Amazon的Echo语音智能系统可以学习用户的习惯，从而制定个性化的语音服务。设备生产商为了快速进入市场，通常会在已有的成熟平台搭建自己的系统，很显然，ARM加Linux的组合统治了目前智能IoT市场。

然而，Linux内核作为统治互联网的开源软件，无时不刻遭受着黑客的攻击，2017年短短几个月（截至7月8日），已有346个安全漏洞被曝出【1】。操作系统内核作为计算机的大管家，通常被认为是系统的可信计算基（TCB）。显然，恶意的Linux内核给运行在其上的敏感用户程序带来严重的威胁。如何在操作系统不可信的情况下，保护敏感应用程序的机密性、隔离性和可信性是非常有挑战但却很重要的研究课题。

在x86平台，已有基于虚拟化的方案来解决这一问题【2，3】。其总体思想是利用影子页表来给应用程序两个视图。如图1所示，在用户态，进程可以正常访问它的数据；但是一旦进入内核，如果处理器要访问用户数据，该数据对应的页会被hypervisor透明的加密。

图1 基于虚拟化的解决方案

对基于ARM的IoT平台，这一思路却行不通。其原因有以下三点：第一，ARM的虚拟化硬件扩展直到2010年才发布【4】，因此很多现有ARM设备不支持该扩展；第二，虚拟机不能提供native的性能，这对于本来就资源受限的ARM IoT移动设备，无疑是很难接受的（当然，ARM的硬件虚拟化技术在服务器市场仍然被广泛使用）【5】；第三，这类方案需要依赖hypervisor，然而，实现一个hypervisor本身需要相当大的TCB， 近年来hypervisor的安全性已经受到严峻的挑战【6】。

相比硬件虚拟化扩展，TrustZone安全扩展【7】已经得到广泛应用，自从在ARMv6上第一次被引入，TrustZone已被部署在其后绝大多数应用处理器上（比如，手机上广泛使用的cotex-a系列）上。简单来讲，具有TrustZone安全扩展的处理器，有两个逻辑core，它们共用一套处理器运算资源。两个core分别运行在安全世界和普通世界中，它们分时复用处理器。每个core有自己独立的安全运行级和系统控制寄存器、内存管理单元（MMU）等，因此，他们可以独立运行自己的操作系统。两个core的不同，体现在对系统资源的访问上，对应两个逻辑core，系统的硬件资源被划分为安全和非安全的。运行在安全世界的core，可以访问所有的硬件资源；而运行在普通世界的core，则只能访问非安全的资源。这些访问控制的配置，储存在只有安全世界才能访问的寄存器中。一般来讲，普通世界的core运行commodity的操作系统，比如Linux；安全世界的core运行轻量级的可信操作系统，从而提供一个可信运行环境（TEE）。ARM的这种架构， 被Android、iOS等移动操作系统广泛利用。比如，在指纹识别技术中，为了保护用户指纹的原始信息，移动操作系统没有权限获取指纹识别器的数据，相反，在安全世界，TEE里的服务进程进行指纹采集和比对等工作，而仅仅只把结果传送给普通世界的移动操作系统。

已有的基于TrustZone的安全技术，其安全服务的API和普通操作系统完全不同，并且相对独立，甚至不能和普通世界交互，仅构成一个自包含的程序逻辑（Pieces of Application Logic， PAL） 。TrustShadow则首次利用TrustZone，来安全的运行未更改的应用程序。一方面，TrustShadow支持已有的代码；另一方面，支持TrustZone的设备非常广泛。因此，TrustShadow可以立即部署在现实世界，并保护已有的、不需要修改的代码。

TrustShadow的基本思想是，可信的进程仍然由普通世界的Linux内核来创建和管理，但是，其运行必须在安全世界中。显然，可信进程所使用的物理内存必须是安全资源，这样可以防止Linux内核对其进行访问。可信进程在安全世界的运行环境，比如页表的创建、系统服务由安全世界的一个轻量级运行时来维护。为了减小其TCB，安全运行时并不直接参与这些服务，而是把他们转发到普通世界的Linux内核，然后，验证其行为是否可信。显然，验证一个行为正确性的复杂性远远低于实现它，因此，安全运行时可以保持很小的TCB。通过这些验证机制，我们确保可信进程的以下安全特性：

1.在运行过程中，可信进程和普通操作系统隔离，普通操作系统不能访问可信进程的数据和代码；

2.载入阶段，保证可信进程的代码的完整性；

3.验证系统调用的返回值，来抵抗Iago攻击【8】；

4.加密文件操作，使得写入磁盘的数据是密文，防止不可信操作系统的访问。

图2展示了TrustShadow如何通过缺页处理（page fault handler）来保证可信进程地址空间的隔离，以及确保代码的完整性。其他技术细节，请参考MobiSys 2017的论文《TrustShadow：Secure Execution of Unmodified Applications with ARM TrustZone》。

图2 代码段缺页处理

如图2所示，当进程由于访问代码而发生缺页，安全运行时把该异常转发给普通世界的Linux内核，Linux找到对应的文件缓存页N-page，安装页表，同时给可信进程分配一个安全的物理页S-page。安全运行时接管后，首先验证S-page是否真的安全资源，其次验证S-page是否和别的物理内存存在doublemapping，只有在安全验证都通过以后，安全运行时才安装可信的页表，并把N-page的代码复制到S-page。最后，使用储存在安全世界的元数据来验证该代码页是否经过篡改，如果没有，则返回可信进程继续执行。至此，普通Linux不能对改代码页进行任何修改。

当然，把进程运行在安全世界，如果有漏洞，则可能被攻击者利用，反过来攻击普通世界的Linux内核，因为安全世界的权限大于普通世界。在TrustShadow的设计中，我们利用以下几点来防止这一隐患：第一，TrustShadow支持未经修改的程序，并不意味着所有程序都可以在安全世界运行。我们需要对可信进程进行严格审查，通过审查的程序，需要绑定一个签名的manifest，安全运行时检查该manifest的有效性来判断是否允许其在安全世界运行；第二，由于可信进程运行在用户空间，即使其有漏洞，也需要进一步exploit安全运行时，才能构成有效攻击；第三，安全运行时进行了极简的设计，其对可信进程暴露的接口很少（仅仅转发异常和检查系统服务返回值），并且5000+的代码量也使得形式化验证成为可能。

我们在NXP的i.MX6q开发版上实现了以上设计，并成功运行了50多个Linux的核心utility，以及Apache、Nginx等大型程序。

【1】 CVEdetails.com. Linux： Vulnerability statistics. https：//www.cvedetails.com/product/47/Linux-Linux-Kernel.html？vendor_id=33

【2】 Chen， Xiaoxin， et al. “Overshadow： a virtualization-based approach to retrofitting protection in commodity operating systems.” ACM SIGARCH Computer Architecture News. Vol. 36. No. 1. ACM， 2008.

【3】 Hofmann， Owen S.， et al. “Inktag： Secure applications on an untrusted operating system.” ACM SIGARCH Computer Architecture News. Vol. 41. No. 1.ACM， 2013.

【4】 ARM Architecture Group. Virtualization Extensions Architecture Specification， 2010. https：//www：arm：com/products/processors/technologies/virtualization-extensions：php.

【5】 Felix Baum. Why you don‘t necessarily need a hypervisor， 2014.http：//embedded-computing：com/guest-blogs/why-you-dont-necessarily-need-ahypervisor/.

【6】 CVEdetails.com. Vmware： Vulnerability statistics. http：//www：cvedetails：com/vendor/252/Vmware：html.

【7】 ARM Ltd. Security technology building a secure system using trustzone technology （white paper）. 2009.

【8】 Checkoway， Stephen， and Hovav Shacham. Iago attacks： Why the system call api is a bad untrusted rpc interface. Vol. 41. No. 1. ACM， 2013.

（责编：杨洁）

为美国宾州州立大学）