我们先理解一下业界具有统一认识的一些概念：

安全启动：启动过程中，前一个部件验证后一个部件的数字签名，验证通过后，运行后一个部件，否则就中止或复位系统。因此它是一个防恶意篡改的手段。

可信启动：启动过程中，前一个部件度量（计算HASH值）后一个部件（通常在后一个部件被签名校验过之后），然后把度量安全的保存下来，比如扩展到TPM的PCR中。后续接入平台后，部件的度量会上报到认证平台，认证平台会有配置一个可信白名单，如果某个部件的版本信息不在白名单里，则认为此设备是不受信任的，因为它可能使用了一个虽然有签名，但可能BUG的版本。因此它是一个可信版本的管理手段。

安全启动/可信启动 是确保系统级别的安全手段，适用于有可信诉求的整机系统，终端设备如手机、STB、路由器等，当然也适用于通用服务器设备。

以上安全启动和可信启动的概念，网上有许多专家在讨论，可以自行进一步理解。然而，如果仅从字面要求试图实施时，我们又会发现许多新的问题，举个例子：安全启动时，确实每一级都被签名校验了，但确定安全吗？某一级如操作系统1分钟前刚刚被校验过，1分钟后还是可信的吗？不见得，这个过程中，操作系统完全有可能已经被非法修改过了。

要做到相对更安全，要么能够做到Runtime的实时校验，即每次使用那一刻都要校验。如果做不到Runtime校验，那就想办法将校验过的数据安全保存起来…相关实现方案和技术其实在有前提的情况下已具备，这是另一个课题。

这个前提是指系统需要是不开放的嵌入式系统，因为不开放，可定制，提供特定的功能/服务，因此整机系统的保护是可行的，并且方案都是很成熟的。

那对于通用计算设备比如服务器产品是个什么样的情况呢？基本上就是这么个事实：

1、系统“全局保护”越来越难以实现，且不切实际。原因是当前开源共享，并且是自由的大环境。操作系统开源，应用开源，用户自由地选择不同版本的操作系统和应用，一切都不在设备厂商的控制中。

2、“全局保护”不可行，那就将保护范围缩小到应用的部分片段--这就是Intel SGX或ARMTrustZone的由来。

因此，Intel SGX或ARM TrustZone是传统的系统保护手段不可行，通用系统设备的保护方案无法借鉴嵌入式系统的方案后，安全技术工作者转变思路后的产物。

接下来我们来理解一下基于这两种技术的应用的工作过程，但此文不讨论这两个安全方案的实现原理。

Intel SGX

网上有相当多的材料，并且都有一个特点：短小精悍。于是我们就看到了非常经典的一个图，足以说明SGX应用的工作原理：

1.应用在设计时，需要考虑所谓的trusted和untrusted两部分，trusted即为处理敏感数据的实现部分

2.实现应用，对于trusted部分，需要使用Enclave定义语言（EDL）来实现需要的逻辑。通过EDL实现的内容，将被执行在安全区域（Enclave）

3.Enclave中的实现可被untrusted的代码调用，当被调用时，命令会通过底层驱动传递Enclave中；

4. Enclave中的数据对外部不可见，也禁止外界的访问（包括系统高权限的代码也不可访问）

5.处理完之后，返回结果，但过程数据仍然在Enclave中；

6.获得返回后，应用的untrusted部分按即定的过程继续执行。

我们可以再看一下EDL的使用示例，这样可以了解应用开发的难易程度：

可以看到，EDL并不是要求用户掌握学习一门新的语言，它的代码仍然是类POSIXAPI，C/C++库构成的，它也可以快速的将已有的实现迁移到Enclave中。

小结：

SGXEnclave完全使用了CPU的隔离能力，不可操作外设、中断等。EDL定义片段属于普通App的一部分，因此多核 、多线程都可以支持。EDL随时随地定义，部署非常灵活方便。但是EDL是定义在代码中的，通过版本的逆向工程，对于数据的处理逻辑，是有可能被窥探的。

ARM TrustZone

TrustZone是标准TEE实现的一种方案，GP的TEE架构和规范标准都是由ARM TrustZone 贡献。当我们讲TrustZone时，可以理解为是在讲GP TEE。则于标准规范，就导致了与SGX不一样的情况，TEE实现有大量的资料可以参考。以下是TEE应用实现的原理：

1.基础设施：与SGX不同的，TEE的功能，依赖于安全OS，首先要确保设备上已经部署了安全OS，并且要确保其是可信的；

2.设计应用，对于需要可信保护的处理过程，需要实现在单独的可应用中（TA）；APP以及TA需要分别开发，物理上他们是两个程序；

3.APP执行到安全处理部分时，它通过TEE标准接口向TA发消息；

4.调用需要进入内核态，通过驱动将消息送到TEE侧；

5.TA收到消息后，来执行即定的数据处理逻辑。

6.最后将结果返回到APP，但过程数据仍然在TEE侧，

TrustZone利用的是CPU时间片切换来模拟了安全世界，这两个世界可以将它理解成一个CPU上处理的两个进程，它们通过上下文切换来将CPU的时间片占满以利用CPU。从安全角度，仅仅分时复用或拟化，是不足以确保安全的，因此ARM另外定义了安全框架，从硬件级别两个世界，包括Timer、TRNG、TZPC、MMU、Cache等相关设备，不同的芯片厂商会有自己的考虑，这个设备可能是双份的，或者是动态切换以达到隔离目的（此处不方便贴上我司920的安全芯片框架）。同时，安全侧也需要有一个可信操作系统执行应用。从原理上，REE侧和TEE侧是对等的，因此并不会性能的差异。应用程序的开发，除了使用TEE定义的标准接口，依赖的都POSIXAPI，使用标准的开发语言。

在部署应用时，SGX只需要在代码中定义即可，在TrustZone中侧需要单独开发部署TA。一般设置厂商都会提供给应用开发者自行部署TA的方法，与SGX相比稍有一点不同，但并不是不可接受（个人观点），这也确实是SGX很明显的一个优势，于是乎，ARM后面有了Newmore这样一个概念。

但也正因为TA与APP是分离的，并且TEE侧是不可查看的，因此数据的处理过程很难以被窥探。

最后，还有一点，网上还有一种声音，认为SGX和TrustZone“没有什么用”，观点的理由是：

“且不说传统的攻击，如SQL注入、溢出攻击,使得攻击者可以直接控制非安全应用，进而通过定义的接口取得数据，即使没有这些漏洞，恶意软件通过其他途径入侵到了OS里面，它是不是可以远程注入一段代码到APP，然后调用接口获取数据？”

这里必须要反驳一下，之所有这个观点，是他没有理解SGX或TrustZone的真正的使用场景。正确的处理方式其实上面的过程描述中我们已经提到了：

“处理完之后，返回结果，但过程数据仍然在Enclave中”

“最后将结果返回到APP，但过程数据仍然在TEE侧”

一个有价值的安全应用，并不会支持将敏感数据通过接口调用返回到非安全侧。

应用的安全与否，无论是SGX还是TrustZone应用，确实很大程度上是依赖开发者的意识。SGX或者TrustZone，它们的价值在于是隐匿敏感数据本身，以及尽可能的隐藏处理敏感数据的处理过程。只有以这个导向，在应用开发时才能有意识地向这个方向去努力。

我们拿媒体数据举例，一看就会明白应该如何正确使用SGX或TrustZone---

高价值的媒体内容在网络传输时，它通常是被DRM加密保护的，只有凭证的订户才可以解密播放。盗版者本身可能就是个订户，在没有SGX、TrustZone等保护时，通过拷贝内存等手段就很容易实现盗版。但有这些技术后，加密的媒体流并不会在非安全侧解密，而是送往安全侧。注意，在SGX、TrustZone解完密之后的媒体，也并不会返回到安全侧，而是使用底层安全驱动，直接送往解码播放了，媒体数据直接在安全侧消费了。

以上是从应用开发者角度来比较SGX与TrustZone的差异。但事实上，两者完全不是一个层面的东西，SGX更适合拿AMD的SEV来比较，因为这两种技术类似，都是基于所谓的realm技术（局部保护）来实现。ARM有最新的newmore方案，但目前还在验证的概念阶段，预计在2023年以后才可能产品化，这个世界变化太快，两年的时间实在是太久，暂不讨论。