作者：djygrdzh
来源：https://zhuanlan.zhihu.com/p/32366874
Trustzone可以追溯到十多年前，ARMv7公布的时候就有了，可惜一直没有什么实际应用。直到近几年开始，才真正的有厂商开始把这个方案大规模用于芯片里。它的基本设计思想是用硬件防护来弥补软件的漏洞。目前看到的主要有五个应用领域：
第一是支付。知乎上有篇文章把支付过程中的利益链分析的非常清楚：为什么 NFC 到目前为止仍然不温不火？简单来说，一方以运营商和银联为代表，用运营商的SIM卡作切入点，支付经POS机走到银联；另一方以支付宝和微信支付为代表，用他们的手机应用作切入点，支付经过互联网公司到银行。这两个阵营各有一帮小弟摇旗呐喊，好不热闹。而Trustzone也有两个分支：ARMv8-M Trustzone和ARMv8-A Trustzone，分别适用于SIM卡和手机支付。不幸的是，ARMv8-M Trustzone完全不适合中国，原因很简单，运营商要求SIM卡的成本要做到6分钱，而完整的实现ARMv8-M Trustzone需要5到10倍于常规MCU的面积，就算使用180nm的工艺都做不下来，更不用说版税和别的费用了，所以SIM卡这条路已经堵死。对于手机支付，三星，联发科，海思和展讯早已在芯片上集成了ARMv8-A Trustzone，为支付提供了硬件支持。但是目前的支付宝和微信支付仍然以软件方案为主，只有在使用指纹支付时才会用到Trustzone，普及基于硬件的安全支付还有一段路要走。而苹果的Apply Pay剑走偏锋，它以NFC卡为切入点，交易走的是POS机，但同时也使用了类似Trustzone的技术来保护密钥和指纹。总而言之，技术不是重点，两种支付方式都可以拿Trustzone来实现，关键是怎么站队。
同样是在手机上，最新的安卓7.0要求必须对关键数据进行保护，包括密钥，指纹等信息。虽然谷歌并没有明确必须用硬件来做防护，但是他对于基于软件虚拟机等方案是持保留态度的。所以要上新版本安卓的小伙伴们千万要注意提早规划，绕过这个坑。
第二是DRM，数字版权管理，也就是正版内容保护。如果用户要在手机上看最新好莱坞大片，那么播放设备必须符合一个标准，这个标准可以用Trustzone来实现。国内已经在积极的推动这个事情，也就是ChinaDRM，估计2017年就有标准出来了。需要强调的是，使用Trustzone实现DRM，本身并不限制盗版，只不过让手机多了一个功能，有了一个看好莱坞大片的渠道。如果不需要，完全可以关闭，对用户没有任何影响。目前在手机的芯片成本上，支持DRM增加的面积并不大，三星，联发科，海思和展讯已经早早的集成了DRM支持了。在国外的机顶盒芯片上，对于版权保护早要求，也早就有方案和认证，有些甚至比目前的Trustzone要求更高。相信随着ARM处理器在机顶盒上的普及，Trustzone会逐渐完善。
第三是无人机芯片，大疆已经走在了最前面，第二名连影子都没看见。无人机上几大应用，图像传输，图像处理，识别，飞控，存储，每一块都有安全的诉求。利用Trustzone可以做到，在芯片里流动的数据，包括视频和应用软件信息，每一步都在安全系统的控制之下，哪怕飞机被人抢去，都需要极大的代价才能拿到闪存以及内存里面的数据。如果以后上安卓或者其他操作系统，哪怕软件系统被黑客攻破，数据和控制还是安全的。最后，如果国家或者行业出台政策，要求实施禁飞区，那么哪怕无人机的主人自己去修改闪存和软件，都可以被强制接管。这些功能必须在芯片设计阶段就考虑到。
第四是物联网。物联网的安全有好几种做法，可以把安全检测放在服务器端或者末端芯片上。末端通常是一个MCU加上传感器和互联模块，面积较小。用硬件trustzone实现的话，加解密和密钥管理等功能会需要额外内模块，可能比MCU本身都大，成本太高。但如果是附加值高的芯片就没什么问题。ARM在2016年专门为物联网发布了MCU上的ARMv8-M Trustzone，用相对Cortex-A系列更低的成本来实现安全。
第五是汽车。在这个领域，ARM在R系列芯片上使用了和手机Trustzone截然不同的技术-虚拟机来实现ARMv8-R Trustzone，在安全的同时兼顾实时性。瑞萨和高通（前NXP）已经在往这条路上探索，国内好像还没听到什么公司有动作。
其他还有一些企业应用的领域，比如存储，一般使用TCG标准。这个标准定义了存储控制器内部和服务器端的加密格式，而这蕴含了安全启动的需求。同时，整个数据流在存储侧全程都是加密的。这些都可以用Trustzone的相应功能来实现。目前有人已经做了实现，不过ARM并没有提供现成的方案，还是需要芯片公司自己软硬件定制。
在服务器上，Intel有基于SGX的防护，而ARM并没有正式提出服务器的安全解决方案，给客户推荐的也不过是照抄手机Trustzone。我看了下SGX的官方PPT， https://software.intel.com/sites/default/files/332680-002.pdf，它是将合法软件的安全操作封装在一个容器中，保护其不受恶意软件的攻击，特权或者非特权的软件都无法访问容器，也就是说，一旦软件和数据位于容器中，即便操作系统或者和VMM（Hypervisor）被攻破，也无法影响容器里面的代码和数据。硬件实现是在正常的MMU之后又加了一层，专门检测是不是属于容器的，同时也会防止Snooping等操作的窥探。设置这个容器的寄存器，指令和独立MMU游离于Hypervisor之外，不能被更高优先级所修改。想法是很好，但SGX仅仅是CPU侧的防护，还是可以通过PCIe和DMA设备直接读取DDR内容的。ARMv9里面也会有类似设计，同时注意所有系统主设备的访问，最后会有介绍。
纵观以上各个领域，Trustzone做了很多在设备端的硬件安全保护，但请注意，Trustzone并不是一个服务器和客户端的完整交互方案，也没有规定密钥的交互规范，对于支付和DRM，还是需要应用层来共同解决。
接下来让我们从技术层面来定义Trustzone到底能做什么：
1.防止操作系统被攻破后关键数据泄密，关键数据存放在特定内存区域，而那块区域，只有安全操作系统才有可能读到。
2.防止通过JTAG等调试接口读到寄存器，缓存，内存或者闪存数据。
3.从芯片制造开始，最初的密钥可以用芯片熔丝实现，往后启动的每一步都需要最高特权级和密钥验证，建立信任链，杜绝软件被替换或者被恶意读取。
4.防止边带攻击，比如量取内存颗粒的信号猜测数据，制造故障让检验模块停止工作，替换外围器件，输入特定数据确定电磁信号特征，打开芯片直接量内部信号线等。
上图是一个典型的ARM SoC内部结构，在这个结构里，Trustzone做的事情是保护数据在芯片内部的安全，不允许非授权的访问，哪怕这个访问来自CPU。初看有些复杂，不过我们可以拆开慢慢分析，从硬件角度开始比软件更清楚。
首先，按照Trustzone的划分，一个芯片内被划分为安全世界和非安全世界。上图中，中间黑色的部分是总线，总线上面是主设备，下面是从设备（主设备中的缓存是例外，这个以后说）。读写请求总是从主设备发往从设备的。
作为从设备，区分它是不是属于安全世界相对简单。如果一个从设备不存在成块的空间映射，比如I2C或者PWM，那么我只要在总线访问它的时候，额外的加入一个管脚(取名为PROT)，就可以告诉它本次访问是不是来自安全世界。如果从设备本身是完全属于被保护的安全世界，不接受非安全的访问，那么只要简单的拒绝，返回错误或者无意义数据即可。同样，如果从设备本身处于非安全世界，那么对于安全和非安全访问，都可以返回正确数据。还有，从设备所处于的世界，是可以动态配置的，且动态配置本身需要处在安全世界，这个以后讨论。
对于块设备，包括闪存，sram和内存等，它们的某些地址块需要处于安全世界，其他的处于非安全世界。为了实现这一点，就需要在它们前面插入一个检验模块（例如图中左方，DDR上面的TZC400），来判断某个地址是不是能被访问。当地址被送到这个检验模块，模块会结合PROT管脚去查表，看看本次访问是不是被允许，然后做相应措施。表本身和之前的动态配置一样，必须是在安全世界里面配置的。
至此，从设备就分析完了，是不是感觉特别简单？还有些细节，在把主设备也讲完后，我们会从系统角度来关注。
对于一般主设备，不考虑自带的缓存时，其实和从设备也差不多，也分为安全和非安全，可以在安全世界动态配置。配置完成后，这些主设备会按照自己所处的世界，驱动PROT管脚和地址来访问从设备，得到相应返回。不过这里的一般主设备不包括中断控制器，系统MMU，调试模块和处理器，接下来对这些例外模块进行具体分析。
首先是处理器。在上图情况，接了CCI总线后，处理器接在缓存一致性端口ACE上（不明白的请参考以前的文章），它的缓存是可以被别人访问的，并且这个访问，是从主设备到主设备（当然，在处理器内部是从端口），不会经过总线送到内存，也不会经过检验模块TZC400。这时就有个漏洞，通过操纵一个非安全世界的模块，比如上图的橙色主设备，假装去读一个被安全世界保护的内存地址。这个地址本来存在于内存，被TZC400保护，可是由于总线的监听功能，读请求有可能被发往处理器缓存，从而绕过保护。为了防止这种情况，处理器在所有的页表和缓存都做了特殊设计，加了一个标志位，标志本缓存行是否属于安全世界。如果别的非安全世界主设备来监听安全世界缓存行，由于安全位不同，处理器会认为这是两个不同地址，哪怕它们的地址一致，返回缓存未命中。这样，就不会把数据泄漏。有人会问，这个标志位来源于页表，改了页表中的这一位不就可以访问了？其实不行。因为安全世界页表位于被保护的内存区域或者缓存，就算破解了操作系统也无法访问。又有人会说，那改了非安全世界的页表中安全位，并伪造一个安全世界的地址，岂不是可以让CPU模拟出一个访问安全世界的传输，送到总线和TZC400？TZC400或者对端缓存一看地址和PROT管脚都是符合要求的，应该就会返回保密数据吧？想法是不错，可是当CPU位于非安全世界时，它会忽略页表中的安全位，所以不可能发出PROT为安全的传输。所以，我们可以对这点放心。
以上是别的主设备访问处理器，那如果处理器本身处于非安全世界，有没有可能访问其他主设备的安全缓存？当然有。所以不要把其他主设备接到ACE端口，以免被监听，一般主设备是不会做缓存上的安全与非安全区分的。接到ACE-Lite接口无所谓，反正设计上就无法被读取缓存数据。除此之外，还存在一个例外，就是GPU。在最新的ARM
G71图形处理器上，是支持双向硬件一致性的。也就是说，GPU也可以被监听缓存的。为了简化设计，图形处理器被设成永远处于非安全世界，CPU尽管读，不在乎，它使用另外一种机制来保护数据，以后介绍。
对处理器缓存熟悉的人可能会想到用跨缓存行的非安全变量来访问被保护的数据。没用的，处理器设计者早就想到这点，要不就是非对齐访问异常（包含exclusive access的时候），要不就不会给你数据，具体到每个处理器有所不同。
还有一个漏洞没堵上，那就是缓存维护，TLB和分支预测操作。ACE端口包含了DVM操作来维护它们，安全性如何保障？同样的，地址中也有安全和非安全位。不过话说回来，DVM操作无非就是无效化某些缓存，分支预测和TLB项，不存在安全数据被读取，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时，才会让原来的中断屏蔽恢复，从而触发中断。此时处理中断的是安全世界的中断程序，处于被保护的内存区域，杜绝非安全世界的程序篡改。
那怎样触发安全与非安全中断呢？这在中断控制器里有定义，早年的定义中只有FIQ可以作为安全中断，后期的可配置，并且，相应的安全世界配置寄存器只有在处理器的安全世界中才可以访问。
SMC指令和中断触发类似，只不过软件就可以触发，切换到Secure
Monitor。这里，非安全软件可以提出触发请求，在通用寄存器填入参数，却无法控制安全世界的处理程序做什么，也依然看不到被保护内存数据。所以防止数据泄密的任务就靠安全操作系统了。
至此，安全启动后的基本硬件防护已经完成，但如果你以为这就是Trustzone，那就错了，精彩的在后面。
我们可以把Trustzone放到实际应用里面看看是不是可行。以DRM举例，如下图：
在播放授权 视频的时候，视频流来自网络或者闪存，它们不需要在安全世界，因为数据本身就是加密过的。然后被解密并放到被保护内存，等待解码。上图中，密码保护和解密是通过安全硬件模块Crypto来完成的，这个我们以后再分析，先处理解密完成后的视频流。此时有两种方案：
第一中，非常自然的，可以把所有的过程在安全世界完成，那么图形处理器，视频处理器和显示模块必须都工作在安全世界，能访问安全世界的数据，才能完成工作。可这样就带来一个问题，那就是驱动。我们知道，图形处理器的驱动是非常复杂的，并且手机上只存在Linux和windows下的图形驱动，和OpenGL ES/DirectX配合。而安全世界的操作系统（TEE，Trusted Execution Environment）是完全不兼容的安全系统，甚至有的都不支持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攒机指南专栏，后续还有AI等相关篇章。
