TrustZone是如何保证硬件安全的？

从技术角度来说，一讲到TEE就会提到TrustZone，这是因为虽然TEE OS实现有多种多样，主芯片厂商也有好几种，但是大部分都是基于Arm的TrustZone架构。

通常说TEE的安全是基于硬件架构的软件保护，那么这个体现硬件安全的TrustZone到底是如何保证安全的呢？我们今天来捋一捋，首先从安全的角度上看，首先明确保护对象是什么？

1，防止系统root后，关键数据或者资源被窃取。

2，防止通过调试接口，获取内存或运行寄存器值。

3，安全启动，必须建立信任根。

4，具备一定的抗攻击功能。

一张来源于Arm官网的经典的架构图描述TrustZone通常如下:

按照Trustzone的划分，CPU被划分为安全世界和非安全世界。上图中，红色代表非安全和绿色代表安全,黑色的部分是总线。

对于一些从设备外设比如指纹来说，很简单的理解可以将SPI口设置为安全总线访问状态，那么设备就处于安全的世界中，就不接受非安全的访问，只要简单的拒绝，返回错误或者无意义数据即可。

对于内存来说，某些地址段处于安全世界，某些处于非安全世界，那么也可以插入一个内存保护模块（TZC400）来检测，判断某个地址是不是能被访问。当地址被送到这个检验模块，模块会去查表，看看本次访问是不是被允许，然后做相应措施。表本身和之前的动态配置一样，必须是在安全世界里面配置的。

对于一般主设备，不考虑自带的缓存时，类似地也分为安全和非安全，可以在安全世界动态配置完成后，这些主设备会按照自己所处的世界，根据配置和地址来访问从设备，得到相应返回。

对于设备访问处理器情况下，对于CPU处理器来说由于其缓存是可以被访问的，并且这个访问，不会经过总线送到内存，也不会经过内存保护模块。这时操纵一个非安全世界的模块，假装去读一个被安全世界保护的内存地址。这个地址本来存在于内存，被地址检测模块保护，但是由于总线的监听功能，读请求有可能被发往处理器缓存，从而绕过保护。

为了防止这种情况，处理器在所有的页表和缓存都做了特殊设计，增加一个标志位，标志本缓存行是否属于安全世界。如果别的非安全世界主设备来监听安全世界缓存行，由于安全位不同，处理器会认为这是两个不同地址，哪怕它们的地址一致，返回缓存未命中。这样，就不会把数据泄漏。这个页表位于安全世界中无法被修改或伪装！因为在非安全世界中的任何模拟伪装，它会忽略页表中的安全位，这个标志位都是无效的。

处理器本身处于非安全世界，有没有可能访问其他主设备的安全缓存？当然有。所以不要把其他主设备接到ACE端口（缓存一致性端口），以免被监听，一般主设备是不会做缓存上的安全与非安全区分的。

GPU也可以被监听缓存的，图形处理器被设成永远处于非安全世界，它使用另外一种机制来保护数据。

对处理器缓存熟悉的人可能会想到用跨缓存行的非安全变量来访问被保护的数据。没用的，处理器设计者早就想到这点，要不就是非对齐访问异常（包含exclusive access的时候），要不就不会给你数据，具体到每个处理器有所不同。

同样的，对于缓存维护，TLB和分支预测操作也有安全位和非安全位区分。总结起来就是防止关键资源被获取是通过配置好安全标志位保护，避免各种缓存操作漏洞。

杜绝了缓存漏洞后，还有别的隐患，比如仿真器。

调试模块可以被用来访问各个从设备，也可以访问和影响处理器内部资源。从设备侧的防护很容易，把调试模块当成一般的主设备处理就行。处理器内部的寄存器，缓存等资源，需要处理器从设计开始，就要为所有资源定义安全级别。被保护的资源对于来自调试模块的未授权访问会被禁止。只有通过安全启动链，安全世界的软件才能打开寄存器SDER，从而允许外部仿真器影响被保护的安全世界资源和处理器运行状态，访问被保护的资源。

那处理器内部的资源是怎么划分的？以ARMv8举例，如下图：

ARMv8的处理器被分成四个特权等级，通常EL0跑用户态程序，EL1内核，EL2虚拟机。EL0-1分为安全与非安全，EL3只有安全世界，EL2不区分，两个世界的切换必须经过EL3。我们谈到的处理器内部资源，包括寄存器，缓存，异常，MMU，很多都会分组，组之间看不到或者低级不可访问高级，从而保证安全。没有分组的，比如通用寄存器，就需要软件来维护，防止非安全世界的看到安全世界的数据。 引起安全切换的会有几种可能：中断和SMC指令。中断分为如下几种情况：

非安全世界下，在EL1或者EL0，当一个非安全中断来临，那么系统没必要切换安全状态，作为一般中断处理，切到EL1即可。 非安全世界下，在EL1或者EL0，当一个安全中断来临，那么系统必须先切到EL3，不然就没法做安全世界切换。 安全世界下，在EL1或者EL0，当一个安全中断来临，没必要做安全世界切换，作为一般中断处理，切到EL1即可。 安全世界下，在EL1或者EL0，当一个非安全中断来临，那么系统必须先切到EL3，不然就没法做安全世界切换。

当跳到EL3的Secure Monitor程序处理上下文切换时，IRQ/FIQ中断屏蔽位不起作用，哪怕打开了也不会触发，直到Secure Monitor处理完，向下跳到相应的安全世界EL1时，才会让原来的中断屏蔽恢复，从而触发中断。此时处理中断的是安全世界的中断程序，处于被保护的内存区域，杜绝非安全世界的程序篡改。

SMC指令和中断触发类似，只不过软件就可以触发，切换到Secure Monitor。这里，非安全软件可以提出触发请求，在通用寄存器填入参数，却无法控制安全世界的处理程序做什么，也依然看不到被保护内存数据。所以防止数据泄密的任务就靠安全操作系统TEEOS了。

至此，安全启动后的基本硬件防护已经完成！

我们可以把Trustzone放到实际应用里面看看是不是可行。以DRM举例，如下图：

在播放授权视频的时候，视频流来自网络或者闪存，它们不需要在安全世界，因为数据本身就是加密过的。然后被解密并放到被保护内存，等待解码。上图中，密码保护和解密是通过安全硬件模块Crypto来完成的，然后处理解密完成后的视频流。此时有两种方案：

第一中，可以把所有的过程在安全世界完成，那么图形处理器，视频处理器和显示模块必须都工作在安全世界，能访问安全世界的数据，才能完成工作。可这样就带来一个问题，那就是驱动。我们知道，图形处理器的驱动是非常复杂的，与安全世界的操作系统TEEOS是完全不兼容的安全系统，甚至有的都不支持SMP，不存在把图形驱动移植上去的可能性，也没有任何意义。这样的话，就只能把图形处理器从流程中挖掉，只留下相对简单也不需要生态的视频和显示模块的驱动，工作在安全世界，而GPU的输出送到显示模块，由显示模块进行混合。这是一种可行的方案，也确实有公司这么做。但是从长远看，图形处理器总是会参与到这个过程的，别的不说，只说VR和AR流行以后，要是虚拟个显示屏出来，上面播放视频，然后放在一个虚拟出的房间，那他们之间肯定是要进行互动的，此时显示模块就需要把视频图层送回GPU进行运算。如果GPU不在安全世界，那就会造成泄密。

为了解决上述问题，有了第二种解决方案，称作TZMP1（Trustzone Media Protection 1），引入了保护世界的概念。保护世界工作于非安全世界，这样才能兼容图形驱动。那安全怎么办？它需要添加四根管脚NSAID，类似于安全世界的PROT信号，只不过做了更细的划分，使得GPU/视频/显示模块要访问被保护内存时，预先定义好了权限。而这个权限的设置，也是通过前文的TZC400来实现的，在安全启动链中就完成。CPU的权限通常是0，也就是最低。而显示控制器权限是只读。

这样一来，我们之前的老问题，恶意缓存监听，又回来了。在新的A73和G71加CCI500/550总线系统里，可以支持双向硬件一致性。这意味着GPU也能被监听。这下大家都在非安全世界，缓存里的安全位不起作用，怎么解决？这需要总线的配合。ARM的总线CCI500/550，有一个保护模式，打开后，不光支持上文的NSAID管脚，还可以在监听的时候，把监听传输替换成缓存行无效化命令，直接让目标把相应缓存行无效化。这样一来，数据还是需要从内存读取，保证安全。并且这个过程对软件透明，无需做任何改动。可是此时，辛辛苦苦设计的硬件一致性就完全起不到加速作用了，性能受到影响。好在运行OpenGL ES的时候，GPU是不会发出共享传输的，CPU也不会没事去监听GPU的数据。而下一代的图形接口Vulkan，会开始使用GPU双向一致性，那时候会有影响。还有一点不利的是，如果同时运行OpenCL和DRM，OpenCL也用不上双向硬件一致性，必须重启系统切换到非保护模式才行。

以上两种方案同时也可用于安全支付，只要把密钥和指纹放在安全内存里，让显示模块单独读取一个安全图层就行。此时，安全图层的数据不可能被处理器上的恶意程序读到，无论显示模块是在安全世界还是保护世界。

在实际使用中，现有的TZC400作为内存保护模块，有几个致命的缺陷。第一，它的配置只能在启动时完成，无法动态改变，也就是说，一旦某块内存给了安全世界，就无法再被非安全世界的操作系统使用，哪怕它是空闲的。在4K视频播放时，往往需要分配几百兆内存，还不止一块。如果一直被占着，这对于4GB内存手机来说是个沉重的负担。怎么解决？只能改成动态配置的硬件。

改成动态后，还会遇到第二个问题。TZC400和它的改进版最多只能支持最小颗粒度为2MB的内存块管理。为什么不弄细些呢？很简单，如果设成4KB，和系统页大小一致，那么4GB的物理内存就需要一百万条目来管理。如果做成片上内存，比二级缓存还大，不现实。而做内存映射，就和MMU一样了，经过CPU的MMU后，数据访问还要再穿越一次MMU，延迟显然大。此外，这一层的MMU无法利用一二级缓存放页表，效率极低。如果继续保持2MB的颗粒，那么Linux在分配内存的时候，很难找到连续的2M物理块，因为他需要512块连续4K物理页来拼接。这样，我们很容易就分配失败。这就是TZMP2V1。

再有一个问题，就是安全世界TEE和非安全世界REE的切换性能。由于安全切换牵涉到上下文的保存，通常它所需要的时间是毫秒级的。在DRM中，由于每一帧都需要进入到TEE来进行密钥操作，每秒钟需要进行几十次切换，累积起来就是一个可观的数字。怎么避免？有一个办法，就是使用一个额外的硬件，在ARM的方案里被称作CryptoCell。它可以接受非安全操作系统世界来的命令，在自己的硬件里执行密码操作。整个过程中不会把安全数据区暴露给CPU，只是把操作结果放在指定非安全内存。这样，CPU就不必进行安全世界上下文切换，只是需要休眠或者轮询结果就可以。当然CryptoCell还有许多其他功能，安全启动，密钥管理，全盘加密时候会用上。

既然TZMP2V1有这么多问题，第三种基于虚拟机的方案就出现了。不过这个方案基本上推翻了Trustzone最初的设计意图，我们来看下图：

在这里，作为内存保护的TZC400完全移除，而系统MMU加了进来。内存保护怎么做？靠物理地址重映射。先看处理器。在启动链中，从EL3向EL2跳的过程时，就定义好保护内存，并且EL2,也就是虚拟机的页表存放于保护内存，EL1的安全页也同样放在保护内存。这样，当处理器进入到EL1，哪怕通过篡改EL1非安全页表的安全位，也最终会被映射到它所不能访问的安全内存，从而起到保护作用。同样的，给处于非安全世界的控制器也加上系统MMU，让设备虚拟化，同样可以控制安全。这就是TZMP2V2。有了系统MMU，页表可以做成4KB大小了，也不用担心CPU那里穿越两次MMU。这时候，也不用担心恶意监听缓存，因为所有穿过二级MMU的访问里，安全位都是经过检验的的。

但是，不看别的，光是为设备加入这些系统MMU，就会增加很多面积。还有，光加MMU不够，还要加入系统的三级甚至四级缓存，才能让MMU效率更高，不然延迟太大。当然，如果设备使用的页表并不很多，可以对MMU简化，比如增大最小颗粒度，减少映射范围，直接使用片内内存。这需要系统设计者来做均衡。对于GPU来说，要支持双向一致性，还得考虑让监听传输通过MMU，不然功能就出问题了。所以，ARM在2016年所定义的TZMP2方案，本质上还是TZMP2V1。TZMP2V2需要到2018年后才有可能出现。

那目前作为过渡方案，应该怎么办呢？可以使用TZMP2v1，然后牺牲一点面积，在类似TAC400的内存访问过滤器上，实现64KB的颗粒度，这样4G空间只需要256K条目就可以实现全映射，并使得查表的延迟保持在1ns左右。每一条目2-4bit属性位，总体64-128KB大小，。在分配物理内存时，使用不同优先级，尽量降低分配64KB内存失败的概率。

如果最终使用了TZMP2V2，那么虚拟化就变成了一个切实需求。然后会发现，ARM的中断和设备的虚拟化还不完善。接下来我从硬件角度解释下虚拟化。

说到虚拟化，先要解释系统MMU。

如上图所示，系统MMU其实很简单，就是个二层地址转换。第一层，虚地址到实地址，第二层，实地址到物理地址。请注意，没有第二层转换时，实地址等同于物理地址。这个模块既可以两层都打开，也可以只开一层，看情况而定。

上图比较清楚的显示了一层映射的过程。其中，设备发出的虚地址请求，会先经过TLB，它里面存了以前访问过的页表项，如果有，就直接返回，没有就往下走到第二步table walk。第二步里，MMU会按照预设的多级基址寄存器，一级级访问到最终页表。如果MMU位于CPU内，那table walk过程中每次访问的基址和表项，都可以存放于缓存中，大大提高效率。如果在设备上，只有内建的TLB表项，后面没有缓存，那未命中TLB的都是访问DDR，效率自然下降。所以CPU和GPU等经常访存的设备，都是自带第一层MMU和缓存。而对于没有内部MMU，切换页表又不是很频繁的设备，比如DMA控制器，可以在下面挂第一层MMU，此时驱动就简单了，直接把应用程序看到的虚地址给DMA的寄存器就行，MMU会自己按照基地址去查找相应页表并翻译，把实地址送到总线。不然，驱动还要自己查找实地址再写入寄存器。

我们前面说过，在TZMP1和TZMP2v1中，内存保护是靠TZC400来完成的。而到了TZMP2v2，取消了TZC400，这时靠虚拟化的二层地址映射。二层映射的过程和一层映射基本一样，不再详述，但是性能问题会被放大。假设在一层中，经过四级基址查到最终页，而在二层中，这每一级的基址查找，又会引入新的四级基址访问。所以至少要经过4x4+4=20次访存，才能确定物理地址。如果没有缓存的帮助，效率会非常低。其他可行的办法是减少基址级数，比如linux只用了三级页表，但即使如此，也需要3x3+3=12次查找。在包含缓存的ARM CPU上，虚拟机的效率可以做到80%以上。而二层MMU应用于设备实现设备虚拟化的时候，就需要小心设计了。

有了系统MMU，我们就有了全芯片虚拟化的基础。那在对系统性能和成本做完平衡，采取合适的系统MMU设计之后，是不是就可以实现虚拟化，并且靠虚拟化实现安全了？没那么容易，还有其它问题需要考虑。

虚拟化脱胎于仿真器，就是在一个平台上模拟出另一个平台。在指令集相同的时候，没有必要翻译每一条指令，可以让指令直接被硬件执行，这样指令的效率算是得到了解决。当然，对于某些特殊指令和寄存器访问，还是需要hypervisor处理的。接着第二个问题，访存。我们前面解释过，对CPU来说，高效的虚拟化访存，就是让指令高效的经过两层翻译，而不是每次访存都需要触发虚拟机EL2的异常，切到Hypervisor，再得到最终物理地址。这一点在没有缺页异常的时候，ARM的虚拟化也已经做到了，而有缺页异常时还是需要Hypervisor处理。再接着是设备访存虚拟化，有了系统MMU，也可以高效做到。再就是处理器和设备中断虚拟化，如下图：

最高效的虚拟中断处理，是GuestOS直接接受自己的虚拟终端，而不必跳转到Hypervisor再回来。这就需要GICv4之后的中断协议，之前的还都不支持。实现上，必须要求中断控制器能支持多个虚拟中断号和虚拟设备号，否则没法正确的发送中断请求。而要支持这一特性，又需要把描述符放在内存，而不是控制器的内部寄存器，否则片上内存放不下。这又进一步引入了延迟。还有，设置中断处理跳转的寄存器不应该被GuestOS访问，否则会有安全隐患。做系统设计时必须综合考虑这些因素。

高效的指令，访存和中断形成了高效的虚拟机。在实际应用中，这类驱动被称作pass-through device，穿透式设备，是最高效的一种。其余的方式，还有完全虚拟化设备（无需改驱动但效率最低）和半虚拟化设备（需要特殊驱动和Hypervisor沟通）。在网络应用中，如果是跑数据面转发，必须使用穿透模式。据我所知，思科开放的VPP(Vector Packet Processing)可以在Intel服务器上做到90%以上的非虚拟化性能，并且可以线性提升多和性能。这靠得是把上文所有的虚拟化特性全部用上，外加Stashing等总线传输技术才能做到。而在ARM平台，支持GICv4的IP得等到2018年才有，做成高效的虚拟机并配上AMBA5的总线，处理器，外加成熟的软件，估计得2020年，和Intel还是有不小的差距。

这里可以顺便介绍下ARMv8-R Trustzone，前面我们说过，它使用了了汽车上的虚拟化来做安全，并且保证了实时性。在正常的虚拟化上，由于存在两个阶段的地址转换，涉及到几十次的访存，延迟大是其次，关键是无法保证确定的访问时间。这在汽车应用上是不可接受的。怎么办？非常简单，第一，去掉虚实转换，大家看到的都是一个物理地址空间，提高效率。第二，只提供二个阶段的地址检查（分别属于应用和虚拟机），并限制检查的表项个数，比如16条，那么就不需要去内存里查找，直接命中片上内存。在中断处理上，减少虚拟中断号和设备号的数量，避免访存。几个措施加起来，就能继续保证确定的较短延迟。当然，ARMv8-R Trustzone本身其实是支持虚地址的，只不过会引入一些延迟，这就需要系统设计者做权衡了。有了ARMv8-R Trustzone的隔离，就可以在同一个芯片上跑不同的操作系统和第三方应用，而不必担心安全问题。在汽车上，之前的应用是AUTOSAR，虚拟化要取代它，还有很长的路要走。好在汽车芯片商，比如瑞萨和NXP，对这一转变非常积极，已经开始芯片的设计了。

再来说说ARMv8-M Trustzone。事实上，在2016年前，是不存在Cortex-M上的Trustzone的。很多号称实现了Turstzone的MCU，只是借用了这个概念，其实在安全设计上是有问题的。

在上图中，使用了ARM的核Cortex-M3和硬件安全IP CryptoCell，APB总线做了PROT位，还在SRAM/Flash和其他所有控制器上加入了地址安全检查，并启用了安全启动链。这样就是符合Trustzone的系统了吗?答案是否定的。这个系统有个致命弱点，如果第三方程序恶意访问机密数据，由于MCU无法区分安全和非安全状态，导致给总线的信号无法实时驱动PROT管脚，从而从设备无法判断到底是不是安全访问。当然，也可以通过软件来拉PROT信号，可是所有程序都是在一个状态下，看到的寄存器都是一致的，恶意程序也能驱动PROT管脚，保护措施就失去了意义。

那难道必须使用ARMv8-M核才能在MCU上做Trustzone吗？也不是。如果在上述系统中，再加一个M3，把它的PROT管脚拉成非安全状态，并把原来M3的PROT管脚拉成安全状态就可以了。第三方应用跑在非安全核，安全应用跑在安全核，他们之间通过硬件mailbox做通讯。并且由于不存在数据缓存，总线也不支持Snooping，也就不存在上文的缓存一致性安全问题。

那真正的ARMv8-M Trustzone是什么样的？如下图：

这里使用了新的M33核，它内部可以区分安全状态，所以就不需要两个核。并且AHB5总线本身就支持PROT管脚，配合CryptoCell IP，就可以实现类似A系列的安全启动和访问了。在M33上，除了实时性之外，还需要把安全部分的硬件尽量做小，否则MCU面积成本太高，不会有人使用。ARM使用了额外的硬件逻辑来帮助定义安全，如下图所示，需要设计者自己顶一个很小的硬件映射表Arbitration Unit，来定义哪些区域是安全的。这样牺牲了灵活性，却省了面积。同时由于没有缓存，也不需要缓存中加入额外的面积帮助判断。

最后，再阐述一下安全启动机制。之前的Trustzone的工作，都是在保证运行时不被恶意程序窃取安全数据。那如何保证系统从启动开始，所有的系统软件都没有被恶意篡改？前面我们提到过芯片制造过程中，用熔丝fuse实现一些特殊的比特位，这些熔丝一旦被写入，就再也无法更改。这一机制可以被用来写入公钥。当然，由于熔丝的成本较高，我们可以只写入公钥的哈希值，而把公钥存于芯片内部的Rom或者片外闪存。启动的时候，熔丝里哈希后的公钥，可以和片外的公钥做对比，确保哈希值未被篡改。然后，再使用这个公钥，去验证所有的启动代码的签名。如果有些启动代码本身需要保密，不被人读懂，可以用对称加密算法加密后，再对对称算法的密钥做签名和验证。这样一直启动到EL3，就可以建立信任链，为Trustzone打下基础。

不过还是有个问题没解决，那就是如何防止设备本身的身份验证问题。如果服务端需要确认某个设备是不是一个可信任节点，就需要设备用非对称算法的私钥对特征字段进行签名，然后发送到服务端。这个过程有可能被物理攻击，从而泄露私钥，芯片本身也有可能被磨片，造成私钥泄露。这时，可以用闪存的RPMB分区保护数据存储，用全盘加密保护传输，或者干脆把私钥存于另外的设备，从需求和成本达成一个平衡。

（本文来自于知乎ARM攒机指南-安全篇材料，内容有删改，如有不妥，请联系安智客）