以下原文：https://segmentfault.com/a/1190000023717761
大家好，我是今天的讲师田洪亮（花名：樱桃），蚂蚁集团技术专家，也是 Occlum 开源负责人。今天我和大家分享一下如何使用 Occlum 的轻松开发机密计算应用以及 Occlum 技术架构和特色。
前言
云计算、大数据、人工智能，我们正处在一个数据爆炸的时代。如何能够在享受和利用海量数据所产生的价值的同时，保证数据的安全和用户的隐私呢？这无异是一个用户、企业和监管部门共同关注的问题。
近年来兴起的机密计算（Confidential Computing），正是为了解决这个问题而来。利用可信执行环境（Trusted Execution Environments，简称 TEE）技术，机密计算使得数据始终保持加密和强隔离状态，从而确保了用户数据的安全和隐私。机密计算可以解决诸多应用场景中“信任”难题，比如多个不互信组织之间的数据融合与联合分析、区块链上的智能合约的机密性保护、公有云平台对外部或内部攻击的防御、高敏感信息（比如密码学材料、医疗档案等）的安全保护等等。
但是，机密计算底层依赖的 TEE 技术——比如目前最成熟的云端 TEE 技术 Intel SGX——也带来了额外的功能限制和兼容问题。这使得机密计算的开发者面领一个巨大的阻碍：应用开发难。
在本文中，我们会首先分析当前 SGX 应用开发者会遇到的各种挑战和痛点，然后介绍蚂蚁集团自研的开源 TEE OS 系统 Occlum 如何大幅降低 SGX 应用开发的门槛，真正做到人人都可以玩转机密计算。
为什么 SGX 应用开发难？
SGX 应用程序是一种基于划分的模型：在用户态的（不可信）应用程序（上图红色部分）可以嵌入 SGX TEE 保护的区域（上图绿色部分），被称为 Enclave。支持 SGX 的 Intel CPU 保证 Enclave 中的受保护内容是在内存中加密的，并且与外界强隔离。外界的代码如果想进入 Enclave 中执行其中的可信代码必须通过指定的入口点，后者可以实施访问控制和安全检查以保证 Enclave 无法被外界滥用。
由于 SGX 应用程序是基于这种划分的架构，应用开发者通常需要使用某种 SGX SDK，比如 Intel SGX SDK、Open Enclave SDK、Google Asylo 或 Apache Rust SGX SDK。但无论使用上述哪种 SDK，开发者会遭遇下面的开发困境：
- 必须将目标应用做二分：开发者需要决定哪些组件应该置于 Enclave 内部，哪些置于 Enclave 外部，以及双方如何通信。对于复杂的应用，确定高效、合理且安全的划分方案本身就是一件颇具挑战的工作，更不要说实施划分所需的工程量。
- 被限定在某个编程语言：无论使用上述哪种 SDK 开发，一个开发者都将被限定在该 SDK 所支持的语言，这通常意味着 C/C++（当使用 Intel SGX SDK、Open Enclave SDK 或 Google Asylo 时），而无法使用 Java、Python、Go 等更加友好的编程语言。
- 只能获得很有限的功能：处于硬件限制和安全考虑，Enclave 中是无法直接访问 Enclave 外的（不可信）OS 的。由于 Enclave 中缺乏 OS 的支持，各种 SDK 只能提供普通不可信环境下的一个很小的功能子集，这使得很多现有的软件库或工具都无法在 Enclave 中运行。
上述困境使得为 SGX 开发应用成为一件十分痛苦的事，制约了 SGX 和机密计算的普及度和接受度。
学会 Occlum 的“三板斧”
Occlum 是一款蚂蚁集团开源的 TEE OS，可以大幅降低 SGX 应用的开发门槛。那到底多低呢？只需要学会 Occlum的三条命令：new、build和run。本节我们以利用 Occlum 在 SGX 中运行一个 Hello World 程序为例进行说明。
这里有一个非常简单的 Hello World 程序。
$ cat hello_world.c
#include <stdio.h>
int main() {
printf("Hello World!\n");
return 0;
}
首先，我们用 Occlum 提供的 GCC 工具链（occlum-gcc）编译这个程序，并验证它在 Linux 上能正常工作。
$ occlum-gcc hello_world.c -o hello_world
$ ./hello_world
Hello World!
然后，我们为这个程序创建一个 Occlum 的实例目录（使用 occlum new 命令）。
$ occlum new occlum_hello
$ cd occlum_hello
该命令会创建一个名为 occlum_hello 的目录，并在该目录中准备一些必要的文件（如 Occlum.json 配置文件）子目录（如 image/）。
接下来，我们基于刚刚编译好的 hello_world 制作一个 Occlum 的 Enclave 文件和可信镜像（使用 occlum build 命令）。
$ cp ../hello_world image/bin
$ occlum build
最后，我们在 SGX 中运行 hello_world（使用 occlum run 命令）。
$ occlum run /bin/hello_world
Hello World!
更复杂的程序也可以用类似上面的流程通过 Occlum 移植进 SGX 中。用户无需理解 SGX 的二分编程模型，无需或只需少量修改应用代码，还可以自由选择编程语言（比如 Java、Python、Go 等）。使用 Occlum，应用开发者可以将宝贵的精力集中在编写应用上，而非为 SGX 做应用移植。
用起来像 Docker 的 TEE OS
在了解了 Occlum 的基本用法和体验之后，很自然地会好奇 Occlum 的技术原理：Occlum 的用户接口为什么这样设计？而简单接口背后的技术架构又是怎样的？本节就试图回答这些问题。
Occlum 的一个设计理念是 Enclave-as-a-Container。在云原生时代，容器至关重要，容器无处不在。容器最常见的实现方式是基于 Linux 的 cgroup 和 namespace（比如 Docker），但也有基于虚拟化的实现（比如 Kata）。我们观察到，TEE 或者 Enclave 也可以作为一种容器的实现手段。因此，为了传达这种理念，同时给用户提供一种熟悉的体验，我们特意将 Occlum 的用户接口设计成与 Docker 和 OCI 标准接近。除了前面提到的 new、build和run 三个命令，Occlum 还提供 start、exec、stop、kill 等命令，其语意与 Docker 同名命令类似。
简单的用户接口隐藏着复杂的实现细节。为了高层次地描述 Occlum 的技术原理，我们分可信的开发环境和不可信的部署环境两个视角来讨论。
在可信的开发环境（上图中的上半部分），用户使用 occlum build 命令打包和制作可信镜像，该可信镜像是利用 Merkel Hash Tree 来保证镜像在上传到不可信的部署环境之后，无法被攻击者篡改。可信镜像的内容是 Occlum 启动时所载入的 rootfs，组织结构与通常的 Unix 操作系统类似，具体内容由用户决定。
在不可信的部署环境（上图中的下半部分），用户使用 occlum run 命令启动一个新的 Occlum Enclave，该 Enclave 中的 Occlum TEE OS 会从可信镜像中载入并执行相应的应用程序。Occlum 向应用程序提供与 Linux 兼容的系统调用，因此应用程序无需修改（或只需少量修改）即可运行在 Enclave 中。应用程序的内存状态由 Enclave 保护，应用程序的文件 I/O 由 Occlum 做自动的加解密，因此可以同时保护应用在内存和外存中数据的机密性和完整性。
更高效、更强大、更安全和更多内容
除了提供类容器的、用户友好的接口以外，Occlum 还有三个主要特色：
- 高效多进程支持：Occlum 实现了一种轻量级的进程，相比此前最先进的开源 TEE OS（Graphene-SGX），进程启动提速 10-1000 倍，进程间通信的吞吐量提升 3 倍（详见我们的论文，链接见文末）；
- 强大文件系统：Occlum 支持多种文件系统，比如保护完整性的文件系统、保护机密性的文件系统、内存文件系统、主机文件系统等等，满足应用的各种文件 I/O 需求；
- 内存安全保障：作为全球首个使用 Rust 语言开发的 TEE OS，Occlum 极大降低了内存安全问题的几率（据统计，Linux 有 50% 的安全漏洞都与内存安全有关），因此更值得信赖；
下面的传送门提供了更多资料：
以下原文：当 Kubernetes 遇到机密计算，阿里巴巴如何保护容器内数据的安全？
8 月 26 日，我们发起了第 6 期 SIG Cloud-Provider-Alibaba 网研会直播。本次直播主要介绍了机密计算的概况， InclavareContainers 开源项目架构、已支持的功能和迭代计划，以及阿里云 ACK-TEE 的发展现状和规划。
本文汇集了此次直播完整视频回顾及资料下载，并整理了直播过程中收集的问题和解答，希望能够对大家有所帮助~阿里巴巴云原生公众号后台回复“826”即可下载相关 PPT。
直播视频回顾链接：https://v.qq.com/x/page/z3143a6agsg.html
机密计算简介
1. 应用容器安全现状
Portworx and Aqua Security 发布的《2019 容器接受度调研》报告显示，安全性成为了用户使用容器技术和业务上云面临的最大挑战，其中数据安全问题最为突出；根据 Risk Based Security 发布的数据泄露报告显示，2019 年数据泄露事件发生的数量和泄露的数据量与 2018 年相比均增加了 50%+。
2. 机密计算时代到来
数据在整个生命周期有三种状态：At-Rest（静态）、In-Transit（传输中）和 In-Use（使用中）。
- At-Rest 状态下，一般会把数据存放在硬盘、闪存或其他的存储设备中。保护 At-Rest 状态的数据有很多方法，比如对文件加密后再存放或者对存储设备加密；
- In-Transit 是指通过公网或私网把数据从一个地方传输到其他地方，用户可以在传输之前对文件加密或者采用安全的传输协议保证数据在传输中的安全，比如 HTTPS, SSL, TLS, FTPS 等；
- 然而 In-Use 状态的数据很长时间内都没有很好的保护的方法，直到机密计算的出现。
机密计算联盟给机密计算的定义是：机密计算是在一个基于硬件的可信执行环境（TEE）中保护数据执行计算。
机密计算的核心功能有：
- 保护 In-Use 数据的机密性：内存中的数据是被加密的，即便被攻击者窃取到内存数据也不会泄露数据；
- 保护 In-Use 数据的完整性：度量值保证了数据和代码的完整性，使用中有任何数据或代码的改动都会引起度量值的变化；
- 保护 In-Use 数据的安全性：相比普通应用，机密计算应用有更小的 TCB（Trusted Compute Base），意味着更小的攻击面，也意味着更安全。，以 Intel SGX 为例，除了 CPU 和可信应用自身以外，其他软硬件的访问都是被拒绝的，包括操作系统、Hypervisor 等。
在 2019 年 Gartner 的《计算基础设施成熟度曲线》中把机密计算也列入其中，虽然还处在早起阶段，这也说明机密计算开始逐步进入大家的视野并得到重视。
在 2020 年 Gartner的《云厂商本地安全解决方案比较》中，阿里云在 Trusted execution enviorments 中拿到一个 H，是因为 2020 年年初阿里云容器服务发布了机密计算产品 ACK-TEE，更多参考链接。
3. 机密计算业务场景
机密计算旨在保护敏感的代码和数据。业务场景有：区块链、秘钥管理、金融、AI、多方计算、数据租赁、边缘计算等。
以多方计算为例，不同用户或厂商之间相互共享数据以便计算挖掘出更大的数据经济价值，但不想把自己的数据泄露给对方。机密计算可以保护共享数据运行在受硬件保护的可信执行环境中，数据在内存中是加密的，从而保证数据不会被泄露。
4. 安全容器与机密计算的区别
除了机密计算外，还有一个与安全相关的概念-安全容器。阿里云在安全容器和机密计算领域都有布局，虽然二者都与安全相关，但它们的定位和应用场景是不同的。
安全容器的定位是隔离，把恶意应用隔离起来，防止它出去对其他应用搞破坏。主要的应用场景有三类：
机密计算的定位是保护，保护应用不会被其他恶意应用进来窃取数据和搞破坏。应用场景是保护敏感代码和数据。
5. TEE 硬件平台
支持 TEE 的硬件平台主要有 3 个：Intel SGX、ARM TrustZone 和 AMD SEV，它们有不同的应用场景和实现方式：
- ARM TrustZone 把硬件资源分为安全世界和非安全世界两部分，所有需要保密的操作在安全世界执行，其余操作在非安全世界执行，安全世界和非安全世界通过一个名为 Monitor Mode 的模式进行转换。典型的应用场景有移动支付、数字钱包等；
- AMD 利用 SEV（AMD Secure Encrypted Virtualizationn），SME（AMD Secure Memory Encryption）和SEV-ES（Secure Encrypted Virtualization-Encrypted State）等技术实现虚拟机的 Guest 内存加密和安全隔离；
- Intel SGX 是 Intel 提供的一组指令，用于提高应用的代码和数据的安全性，用户可以把敏感数据放入到 Encalve 中，Enclave 是一种受保护的可信执行环境。
阿里云 ACK-TEE 和开源项目 Inclavare Containers 都是基于 Intel SGX 实现的机密计算。
6. Intel SGX 有更小的 TCB(Trusted Computing Base)
按照普通方式部署敏感应用，应用会依赖操作系统、VMM、硬件甚至是云厂商，TCB 非常大，面临的攻击面也非常大。只要 TCB 中只要有一处遭到攻击，应用都有数据泄露和破坏的风险。
而把敏感应用部署在 Intel SGX 的 TEE 中，TCB 只有 CPU 和 TEE 本身。一方面攻击面变得很小，另一方面 TEE 的安全机制也会使应用更安全。
7. 基于 Intel SGX 的可信应用开发和使用流程
Intel SGX 把应用分成了可信区和不可信区。用户可通过在 EDL（Enclave Definition Language）中定义可信区和不可信区以及用到的函数。这些函数用户可信区和不可信区之间的通信，分为 ECALL 和 OCALL。ECALL 用于不可信区访问可信区的数据，OCALL 用于可信区访问不可信区的数据。
基于 Intel SGX 的可信应用开发和使用流程如下：
- 申请秘钥：向 Intel 申请 SGX 相关的商业签名加密密钥；
- 安装环境：
- 安装 Intel SGX 驱动
- 安装 SGX SDK 和 PSW
- 安装 AESM 服务
- 开发应用：
- 明确应用可信区中须保护的代码和数据；
- 编写 EDL 文件，明确 ECALL 和 OCALL 函数；
- 编写可信区代码和非可信区代码；
- 编译构建
- 使用 sgx_edger8r 基于 edl 文件生产用于 ECALL 的不可信区的代理函数和用于 OCALL 的可信代理函数；
- 编译 Enclave动态链接库文件；
- 签名上一步骤的 Enclave 动态链接库文件；
- 编译应用，打包镜像。
- 用 Docker 运行容器
Inclavare Containers 保护敏感应用和数据
1. Inclavare Containers 的目标和价值
Inclavare，是 Enclave 一词的拉丁语词源，读音是 [ˈinklɑveə]。Enclave 指的是一种受保护的执行环境，能为其中的敏感和机密数据提供基于密钥学算法的强安全隔离，阻止不可信的实体访问用户的数字资产。
Inclavare Containers 是由阿里云操作系统安全团队和阿里云云原生容器服务团队主导，并联合了阿里经济体内多个研发团队（蚂蚁安全计算团队、云安全团队、语言 runtime 团队等）共同研发的面向机密计算场景的开源容器运行时技术栈。
当前机密计算在云原生场景中提供的技术，有很多缺陷和不足：
- 使用和开发成本都比较高；
- 容器化和对接 Kubernetes 的成本和复杂度高;
- 服务提供商提供的技术解决方案也相对单一
由于以上原因，非常不利用机密计算技术的普及和应用。而 Inclavare Containers 目的就是为业界提供一款面向机密计算领域的开源容器运行时引擎和安全架构，其价值在于：
- 抹平机密计算的高使用门槛，为用户提供与普通容器一致的使用体感；
- 基于处理器提供的多种硬件安全技术，为用户的工作负载提供多种不同的 Enclave 形态，在安全和成本之间提供更多的选择和灵活性。
2. Inclavare Containers 架构
在介绍 Inclavare Containers 架构之前，先介绍一下架构中各个组件的作用：
- kubelet：Kubernetes 集群中每个 Node 节点上运行的主要“节点代理”，负责与 Apiserver 的通信和管理节点上 Pod；
- Containerd：一个工业级标准的容器运行时，它强调简单性、健壮性和可移植性，Containerd 可以在宿主机中管理完整的容器生命周期：容器镜像的传输和存储、容器的执行和管理、存储和网络等；
- shim-rune：为容器运行时 rune 提供的 shim，主要负责管理容器的生命周期、把普通镜像转换成 TEE 镜像；
- rune：rune 是一个命令行工具，用于根据 OCI 规范在容器中生成和运行 Enclave。 rune 是在 runc 代码基础上开发的，既可以运行普通 runc 容器也可以运行 Enclave 容器；
- SGX LibOS：SGX LibOS 是为了让普通应用在不做或做很少更改的情况下，就能够在 Intel SGX 上运行起来。目前 Inclavare Containers 支持的 LibOS 有 Occlum，Graphene-SGX 正在对接中；
- 语言 Runtime：LibOS 对多语言的支持，比如 Occlum 中提供了 Golang 和 JDK 语言运行时；
- PAL-API：rune 和 LibOS 之间通信的接口。比如 pal_init 用于初始化 Enclave，pal_create_process 用于创建 Encalve。
- liberpal.so：是实现了 PAL-API 的 Linux 动态库，主要负责 rune 和 LibOS 的通信。
Inclavare Containers 的工作流程如下：
- kubelet 向 Containerd 发起 CRI（Container Runtime Interface） 请求，比如请求创建一个 Pod
- Containerd 中有一个 cri-containerd 的插件实现了 CRI 接口，Containerd 接收到请求后，把请求转给 shim-rune
- shim-rune 既可以创建 runc 容器也可以创建 rune 容器。在创建 runc 和 rune 容器的处理流程也有差异：
- 创建 runc 容器：与创建普通 runc 容器过程完全一样，比如 Pod 的 pause 容器就是 runc 容器。
- 创建 rune 容器：利用 LibOS 把普通镜像转换成 TEE 镜像，rune 会在容器内创建 Enclave 并把应用运行在 Enclave 中。
- rune 加载 liberpal.so，用于 rune 与 LibOS 的通信。
- rune 把 Intel SGX 驱动载入容器内，并在容器内创建 1 号进程 init-runelet，再由 init-runelet 创建 Encalve。Enclave 是一个受 Intel SGX 保护的可信执行环境，Enclave 内包含：LibOS、语言 Runtime 和 应用本身。至此一个可信应用就运行起来了。
总结下来，Inclavare Containers 的特点有：
- 将 IntelSGX 与容器生态结合，兼容 OCIRuntime 和 OCI 镜像标准，实现 Enclave 容器形态；
- 与 Kubernetes 生态无缝整合；
- 基于 LibraryOS 技术，改善 IntelSGX 引入的约束条件所带来的兼容性问题；
- 提供对高级语言 Runtime 的支持，进一步提升兼容性；
- 定义通用的 EnclaveRuntimePALAPI 规范，构建 EnclaveRuntime 生态。
3. shim-rune 工作流程
shim-rune 包含两部分 Core 和 Carrier，它们的作用分别是：
- 管理容器生命周期
- 利用 LibOS 把普通容器转换为 TEE 镜像
shim-rune 的工作流程为：
- 以容器镜像为输入，利用 LibOS 生成未签名的 Enclave 动态库；
- 从 Enclave 动态库中导出签名材料；
- 以签名材料为输入，请求签名服务进行签名，返回的内容有摘要文件和公钥；
- 生成签名的动态库；
- rune 加载签名的动态库，创建并启动 Enclave。
4. 客户端签名与服务端签名
Inclavare Containers 支持客户端签名和服务端签名两种工作方式，两种工作方式的差异如下：
相比客户端签名，服务端签名优点如下：
- 降低了开发者使用门槛，开发者不需要掌握 Intel SGX 的技术，按照 LibOS 要求构建出普通镜像即可；
注意：每种 LibOS 对普通镜像也有一定要求，比如 Occlum 只支持 musl libc 而不支持 glibc，所以 glibc 应用需要改造为 musl libc 应用之后才能在 Inclavare Containers 中运行起来。
- 用户不需要自己向 Intel 申请商业证书；
- 可运行在 Kubernetes 集群中。
5. 多团队共建合作
Inclavare Containers 项目是由多个团队共建合作而成的，各组件作用和团队分工如下：
- Occlum：由蚂蚁安全计算团队自研的基于 Intel SGX 技术并实现了内存安全的多进程 Library OS
- Graphene-SGX：基于 IntelSGX 技术并可以运行未经修改程序的开源 library OS
- Dragonwell：由阿里编译器团队定制的 LTS OpenJDK 发行版本
- sgx-device-plugin：由阿里云容器服务团队和蚂蚁安全计算团队针对 IntelSGX 联合开发的 Kubernetes Device Plugin
- AliyunLinux：由阿里 BaseOS 团队对 Inclavare Containers 提供全栈适配 aliyun linux 的支持
6. Inclavare Containers 开源项目
Inclavare Containers 是业界首个面向云原生的机密计算场景下的开源容器运行时技术栈，被阿里巴巴开源委员会评为重点开源项目。并且已经加入到官方机密计算 OCIRuntime 参考实现列表。
目前支持的功能有：
- 支持通过 K8s 和 Docker 启动 Enclave 容器
- 支持 Occlum 和 Graphene 两个主流 LibOS
- 支持 Java 和 Golang 语言 Runtime
该项目每个月月底进行一次发布，面向社区提供 CentOS 和 Ubuntu 的 binary release，并对内提供 AliyunLinux 发行版本。
7. Inclavare Containers 里程碑
8. 2020 年机密计算技术业产业
ACK-TEE
1. 简介
ACK-TEE 于 2019 年 9 月立项
功能：
- 对数字资产（算法、数据、代码）有强安全诉求的云用户提供基于硬件加密技术的可信执行环境(TEE)
- 降低机密计算技术的应用门槛
- 简化可信/机密应用的开发、交付和管理成本。
合作团队：阿里云容器服务团队、操作系统内核团队、云安全团队、蚂蚁安全团队和运行时语言团队
定位：云原生机密计算容器平台
使命：让天下没有难用的机密计算
产品原则：可信安全、易开发交付、标准开放、云原生
2. ACK-TEE 1.0
ACK-TEE 1.0 于 2020 年 1 月份上线
目标用户群体：原生 SGX 用户
全新 K8s 托管集群形态：机密计算专用集群，支持 Intel SGX1。
复用 Managed K8s 已有能力，包括各种云产品集成，K8s 集群运维能力，降低 K8s 集群的运维复杂度；
支持 EPC 加密内存的管理和调度，降低用户使用 SGX 设备的复杂度。
3. ACK-TEE 2.0
ACK-TEE2.0 计划在 2020 下半年上线
功能：支持原生应用在 TEE 中运行起来
目标用户：没有掌握机密计算技术但有数据安全需求的用户
方案
- 把普通镜像转换成 TEE 镜像后运行在 TEE 中；
- 通过 controller 提供安全可信的服务组件，如 KMS-Enclave-Plugin 等。
Q & A
Q1：这个依赖于 Intel 的芯片？为啥还需要单独找 Intel 申请密钥？
A1：Intel 芯片能保证应用执行在基于硬件的 Enclave （一种可信执行环境）中，保证应用的安全，但不能保证创建者一定是合法的。而在构建 Enclave 时我们会用 Intel 的秘钥对其签名，保证使用者是合法的。
Q2：Inclavare Containers 本质上是一个容器运行时实现吗？它能完全替代 Docker 容器运行时的场景吗？
A2：Inclavare Containers 是一个软件栈，它包含了 rune、shim-rune、runelet 等多个工具。其中 rune 是一个容器运行时，它是在 runc 代码基础上开发的。既可以运行普通 runc 容器，也可以跑有 Enclave 的容器。功能上说，可以替代 Docker 容器运行（runc）时，但最大的意义在于运行 Enclave 容器，保证代码和数据的安全。
Q3：应用的性能有多少影响，有做过类似的测试吗？
A3：Inclavare Containers 的重点是解决数据安全问题的。底层是基于 Intel SGX 的技术，目前 Intel SGX1 的 ECP 只有 128 MB 内存，相比原生容器应用的性能肯定会差很多。
Q4：所以理解下来，只把它用在最核心的需要 in-use 加密的地方，对吗？
A4：是的，保护 In-Use 代码和数据的安全是机密计算的最大价值。
Q5：ACK 现在有这个使用方法和 sample 吗？
A5：ACK 里有托管版“加密计算”，即分享里讲到的 ACK-TEE 1.0。但面向客户是 SGX 原生客户，需要客户自己基于 SGX 做应用改造和构造镜像。ACK-TEE 2.0 还在规划中，计划年底上线，会把 Inclavare Containers 的能力移植过来。我理解你是想要 ACK-TEE 2.0 的 sample 是吗？如果有兴趣，你可以按照 Inclavare Containers 0.3.0 的文档，搭建一个支持机密计算的 Kubernetes 集群。
以下原文：一篇了解TrustZone
这篇文章源于老板想了解TrustZone，要求我写一篇文章简单介绍TrustZone的原理。既然是给领导看的，只介绍原理哪里够，因此也添加了公司自己现有TEE环境的设计、实现和发展，也顺带加入了一些题外话。也是因为要给领导看，所以文章也不能涉及太多技术细节，包括TrustZone模块的详细设计以及示例代码等，所以只从总体上讲解了什么是TrustZone，TrustZone是如何实现安全隔离的、TrustZone相关的一些资源等。
如果你之前对TrustZone亦无所知，好吧，本文或许值得你一看；如果你已经了解了TrustZone，想知道更多的实现细节，抱歉，本文并不适合你，或许阅读ARM官方网站和文档以及各开源项目源码是更好的选择。
本文先交代TrustZone的安全背景，然后从较高层次展开介绍TrustZone的工作机制和原理（包括AXI总线架构、CPU、内存和中断模型，以及安全隔离机制），列举了几个常见ARM平台上的实现以及当前博通ARM平台上的状况，最后附带一些TrustZone相关的开源项目以及其他资源链接，全文约7500字。（由于涉及安全的原因，本文已经删掉介绍公司自己平台相关的部分）。
本文内容主要来源于网络，综合了网上的多篇文章，也加入了一些自己的理解，重新组织了文章结构使其便于理解。
主要参考的文章包括：
本文还参考了贴吧、知乎等部分文章，由于涉及较多，无法一一列举，再次对原作者的付出一并表示感谢！
除上面列举的资源外，本文主要资料参考了ARM官方对TrustZone的介绍，主要有：
事实上，前面多篇文章的细节也来源于官方文档。
本人不保留本文的所有权，欢迎转载本文，让更多的人来了解TrustZone。由于不想再次以类似 《TrustZone原理介绍》 一类作为标题，但又不知道以什么作为标题贴切，所以随手用了现在标题党的套路，抱歉。
1. TrustZone介绍
1.1 安全背景
在介绍TrustZone前有必要简单回顾下目前的一些安全手段。
CPU通过内存映射手段给每个进程营造一个单独的地址空间来隔离多个进程的代码和数据，通过内核空间和用户空间不同的特权级来隔离操作系统和用户进程的代码和数据。但由于内存中的代码和数据都是明文，容易被同处于内存中的其它应用偷窥，因此出现了扩展的安全模块，应用将加密数据送往安全模块，由安全模块处理完后再返回结果给相应的应用。
很多消费电子设备都使用扩展的安全模块来确保数据安全，目前常见的方式有：
-
外部挂接硬件安全模块
数据的处理交由外部的安全模块实现，这些模块能够保护自己的资源和密钥等数据的安全，如SIM卡、各种智能卡或连接到外部的硬件加解密模块等，但其同主芯片的通信线路暴露在外部，容易被监听破解。另外，通信的速率比较低。
-
内部集成硬件安全模块
将外部安全模块的功能集成到芯片内，因此一个芯片上至少有两个核：一个普通核和一个安全核。优点是核与核之间的通信在芯片内部实现，不再暴露在外面。缺点是核之间的通信速度仍然较低，而且单独的安全核性能有限，还会会占用SoC面积，成本较高。
1.2 TrustZone是个什么鬼？
TrustZone是ARM针对消费电子设备设计的一种硬件架构，其目的是为消费电子产品构建一个安全框架来抵御各种可能的攻击。
TrustZone在概念上将SoC的硬件和软件资源划分为安全(Secure World)和非安全(Normal World)两个世界，所有需要保密的操作在安全世界执行（如指纹识别、密码处理、数据加解密、安全认证等），其余操作在非安全世界执行（如用户操作系统、各种应用程序等），安全世界和非安全世界通过一个名为Monitor Mode的模式进行转换，如图1：
图1. ARM的安全世界和非安全世界
处理器架构上，TrustZone将每个物理核虚拟为两个核，一个非安全核（Non-secure Core, NS Core），运行非安全世界的代码；和另一个安全核（Secure Core），运行安全世界的代码。
两个虚拟的核以基于时间片的方式运行，根据需要实时占用物理核，并通过Monitor Mode在安全世界和非安全世界之间切换，类似同一CPU下的多应用程序环境，不同的是多应用程序环境下操作系统实现的是进程间切换，而Trustzone下的Monitor Mode实现了同一CPU上两个操作系统间的切换。
AMBA3 AXI(AMBA3
Advanced eXtensible Interface)系统总线作为TrustZone的基础架构设施，提供了安全世界和非安全世界的隔离机制，确保非安全核只能访问非安全世界的系统资源，而安全核能访问所有资源，因此安全世界的资源不会被非安全世界（或普通世界）所访问。
设计上，TrustZone并不是采用一刀切的方式让每个芯片厂家都使用同样的实现。总体上以AMBA3 AXI总线为基础，针对不同的应用场景设计了各种安全组件，芯片厂商根据具体的安全需求，选择不同的安全组件来构建他们的TrustZone实现。
其中主要的组件有：
- 必选组件
- AMBA3 AXI总线，安全机制的基础设施
- 虚拟化的ARM Core，虚拟安全和非安全核
- TZPC (TrustZone Protection Controller)，根据需要控制外设的安全特性
- TZASC (TrustZone Address Space Controller)，对内存进行安全和非安全区域划分和保护
- 可选组件
- TZMA (TrustZone Memory Adapter)，片上ROM或RAM安全区域和非安全区域的划分和保护
- AXI-to-APB bridge，桥接APB总线，配合TZPC使APB总线外设支持TrustZone安全特性
除了以上列出的组件外，还有诸如 Level 2 Cache Controller, DMA Controller, Generic Interrupt Controller等。
逻辑上，安全世界中，安全系统的OS提供统一的服务，针对不同的安全需求加载不同的安全应用TA(Trusted Application)。 例如：针对某具体DRM的TA，针对DTCP-IP的TA，针对HDCP 2.0验证的TA等。
图2是一个ARM官网对TrustZone介绍的应用示意图：
图2. 基于TrustZone的应用示意图
图中左边蓝色部分Rich OS Application Environment(REE)表示用户操作环境，可以运行各种应用，例如电视或手机的用户操作系统，图中右边绿色部分Trusted Execution Envrionment(TEE)表示系统的安全环境，运行Trusted OS，在此基础上执行可信任应用，包括身份验证、授权管理、DRM认证等，这部分隐藏在用户界面背后，独立于用户操作环境，为用户操作环境提供安全服务。
可信执行环境（TEE, Trusted Execution Environment）是Global Platform（GP）提出的概念。对应于TEE还有一个REE(Rich Execution Environment)概念，分别对应于安全世界(Secure World)和非安全世界(Non-secure World, Normal World)。
GlobalPlatform（GP）是跨行业的国际标准组织，致力于开发、制定并发布安全芯片的技术标准，以促进多应用产业环境的管理 及其安全、可互操作的业务部署。目标是创建一个标准化的基础架构, 加快安全应用程序及其关联资源的部署，如数据和密钥，同时保护安全应用程序及其关联资源免受软件方面的攻击。
2. TrustZone原理和设计
以下主要从TrustZone的总线设计，CPU设计(包括处理器模型、内存模型和中断模型)和安全隔离机制来介绍TrustZone的设计和工作原理。
2.1 总线设计
设计上，TrustZone 在系统总线上针对每一个信道的读写增加了一个额外的控制信号位，这个控制位叫做Non-Secure或者NS位，是AMBA3 AXI总线针对TrustZone作出的最重要、最核心的扩展设计。
这个控制信号针对读和写分别叫做ARPORT[1]和AWPORT[1]：
- ARPROT[1]: 用于读操作(Read transaction), 低表示Secure, 高表示Non-Secure
- AWPROT[1]: 用于写操作(Write transaction), 低表示Secure，高表示Non-Secure
总线上的所有主设备(master)在发起新的操作(transaction)时会设置这些信号，总线或从设备(slave)上解析模块会对主设备发起的信号进行辨识，来确保主设备发起的操作在安全上没有违规。
例如：硬件设计上，所有非安全世界的主设备（Non-Secure masters）在操作时必须将信号的NS位置高，而NS位置高又使得其无法访问总线上安全世界的从设备（Secure Slaves），简单来说就是对非安全世界主设备发出的地址信号进行解码时在安全世界中找不到对应的从设备，从而导致操作失败。
NS控制信号在AMBA3 AXI总线规范中定义。可以将其看作为原有地址的扩展位，如果原有32为寻址，增加NS可以看成是33位寻址，其中一半的32位物理寻址位于安全世界，另一半32位物理寻址位于非安全世界。
当然，非安全世界的主设备尝试访问安全世界的从设备会引发访问错误，可能是SLVERR(slave error)或者DECERR(decode error)，具体的错误依赖于其访问外设的设计或系统总线的配置。
在TrustZone出现前，ARM的外设基于AMBA2 APB (Advanced Peripheral Bus)总线协议，但是APB总线上不存在类似AXI总线上的NS控制位。为了兼容已经存在的APB总线设计，AMBA3规范中包含了AXI-to-APB bridge组件，这样就确保基于AMBA2 APB的外设同AMBA3 AXI的系统兼容。AXI-to-APB bridge负责管理APB总线设备的安全事宜，其会拒绝不合理的安全请求，保证这些请求不会被转发到相应的外设。
例如：新一代的芯片可以通过增加AXI-to-APB bridge组件来沿用上一代芯片的设计来使其外围设备可以支持TrustZone。
2.2 处理器设计
2.2.1 处理器模型
TrustZone中，每个物理处理器核被虚拟为一个安全核(Secure)和一个非安全核(Non-Secure)，安全核运行安全世界的代码，非安全核运行除安全世界外的其它代码。由于安全世界和非安全世界的代码采用时间片机制轮流运行在同一个物理核上，相应的节省了一个物理处理器核。
多核处理器上，也有建议说让将某一个或几个核指定为安全专用核，只运行安全系统代码来构建安全世界，其余核运行非安全代码，暂不清楚目前有哪些平台采用这个实现。
图3中，系统有4个物理核，每个又分为两个虚拟核（安全核和非安全核）的情况：
图3. 多核处理器上的安全核和非安全核
2.2.2 L1内存模型
MMU是一种硬件电路，它包含两类部件，一类是分段部件，一类是分页部件，对应于内存管理的分段机制和分页机制。分段机制把一个逻辑地址转换为线性地址；接着，分页机制把一个线性地址转换为物理地址。
当CPU访问一个虚拟地址时，这个虚地址被送到MMU翻译，硬件首先把它和TLB中的所有条目同时(并行地)进行比较，如果它的虚页号在TLB中，并且访问没有违反保护位，它的页面会直接从TLB中取出而不去访问页表，从而提高地址转换的效率。
安全世界和非安全世界都有自己的虚拟MMU，各自管理物理地址的映射。实际上只是两个世界都有一份TTBR0、TTBR1、TTBCR寄存器，因此就会对应两个MMU表。
尽管MMU有两套，但TBL缓存硬件上只有一套，因此TBL对于两个世界来说是共享的，其通过NS位来标志其每一项具体属于哪一个世界。这样在两个世界间进行切换时不再需要重新刷新TLB，提高执行效率。
对于TLB共享并不是硬性规定的，部分芯片在两个世界间切换时可能通过硬件部分或全部刷新TLB。
同TLB类似，硬件上两个世界共享一套Cache，具体的Cache数据属于哪一个世界也由其NS位指定，在世界间切换也不需要刷新Cache。
2.2.3 中断模型
基于TrustZone的处理器有三套异常向量表：
- 一套用于非安全世界，
- 一套用于安全世界，
- 还有一套用于Monitor模式。
与之前非TrustZone的处理器不同的是，这三套中断向量表的基地址在运行时可以通过CP15的寄存器VBAR(Vector Base Address Register)进行修改。
复位时，安全世界的中断向量表由处理器的输入信号VINITHI决定，没有设置时为0x00000000，有设置时为0xFFFF0000；非安全世界和Monitor模式的中断向量表默认没有设置，需要通过软件设置后才能使用。
默认情况下，IRQ和FIQ异常发生后系统直接进入Monitor模式，由于IRQ是绝大多数环境下最常见的中断源，因此ARM建议配置IRQ作为非安全世界的中断源，FIQ作为安全世界的中断源。这样配置有两个优点：
- 当处理器运行在非安全世界时，IRQ直接进入非安全世界的处理函数；如果处理器运行在安全世界，当IRQ发生时，会先进入到Monitor模式，然后跳到非安全世界的IRQ处理函数执行
- 仅将FIQ配置为安全世界的中断源，而IRQ保持不变，现有代码仅需做少量修改就可以满足
将IRQ设置为非安全世界的中断源时系统IRQ的切换见图4：
图4. IRQ作为非安全世界的中断源
2.2.4 系统模式切换
基于TrustZone的系统有三种状态，安全世界、非安全世界和用于二者切换的Monitor Mode。
协处理器CP15的寄存器SCR(Secure Configuration Register)有一个NS位用于指示当前处理器位于哪一个世界，该寄存器在非安全世界是不能访问的。当CPU处于Monitor Mode时，无论NS位是0还是1，处理器都是在安全世界运行代码。因此Monitor Mode下总是安全世界，但如果此时NS为1，访问CP15的其它寄存器获取到的是其在非安全世界的值。
非安全世界到Monitor模式的切换
处理器从非安全世界进入Monitor Mode的操作由系统严格控制，而且所有这些操作在Monitor Mode看来都属于异常。
从非安全世界到Monitor Mode的操作可通过以下方式触发：
- 软件执行SMC (Secure Monitor Call)指令
- 硬件异常机制的一个子集（换而言之，并非所有硬件异常都可以触发进入Monitor Mode），包括：
- IRQ
- FIQ
- external Data Abort
- external Prefetch Abort
Monitor Mode
Monitor Mode内执行的代码依赖于具体的实现，其功能类似于进程切换，不同的是这里是不同模式间CPU状态切换。
软件在Monitor Mode下先保存当前世界的状态，然后恢复下一个世界的状态。操作完成后以从异常返回的方式开始运行下一个世界的代码。
为什么安全模式和非安全模式不能直接切换？
非安全世界无权访问CP15的SCR寄存器，所以无法通过设置NS来直接切换到安全世界，只能先转换到Monitor Mode，再到安全世界。
如果软件运行在安全世界(非Monitor Mode)下，通过将CP15的NS位置1，安全世界可以直接跳转到非安全世界，由于此时CPU的流水线和寄存器还遗留了安全世界的数据和设置，非安全模式下的应用可以获取到这些数据，会有极大的安全风险。因此，只建议在Monitor Mode下通过设置NS位来切换到非安全模式。
综上，安全世界和非安全世界不存在直接的切换，所有切换操作都通过Monitor Mode来执行。
图5展现了安全世界和非安全世界之间的切换方式：
图5. 安全世界和非安全世界之间的切换
2.3 隔离机制
除了CPU执行时实行安全世界和非安全世界的隔离外，AMBA3 AXI总线提供了外设隔离的基础。
2.3.1 内存隔离机制
这里的内存指外部的DDR和片上的ROM以及SRAM，其隔离和保护通过总线组件TZASC和TZMA的设置来实现。
- TZASC (TrustZone Address Space Controller)
- TZASC可以把外部DDR分成多个区域，每个区域可以单独配置为安全或非安全区域，非安全世界的代码和应用只能访问非安全区域。TZASC只能用于内存设备，不适合用于配置块设备，如Nand Flash。
- TZMA (TrustZone Memory Adapter)
- TZMA可以把片上ROM和SRAM隔离出安全和非安全区域。TZMA最大可以将片上存储的低2MB配置为安全区域，其余部分配置为非安全区域。大小划分上，片上安全区域可以在芯片出厂前设置为固定大小，或运行时通过TZPC动态配置。TZMA使用上有些限制，其不适用于外部内存划分，而且也只能配置一个安全区域。
2.3.2 外设隔离机制
外设上，基于APB总线的设备不支持AXI总线的NS控制信号，所以AXI到APB总线需要AXI-to-APB bridge设备连接，除此之外，还需要TZPC (TrustZone Protection Controller) 来向APB总线上的设备提供类似AXI上的NS控制信号。
由于TZPC可以在运行时动态设置，这就决定了外设的安全特性是动态变化的，例如键盘平时可以作为非安全的输入设备，在输入密码时可以配置为安全设备，只允许安全世界访问。
2.3.3 隔离机制示意图
整个系统内存和外设隔离机制示意图见图6.
图6. 系统内存和外设隔离机制示意图
此图来源于网上，实际上TZPC还连接到片内的ROM/RAM设备上，用于配置片上存储的安全区域。
2.4 安全启动
AMBA3 AXI总线机制隔离出安全世界和非安全世界，但这是系统启动之后的事情。如何确保系统本身是安全的呢？这就涉及到系统启动的过程。
系统上电复位后，先从安全世界开始执行。安全世界会对非安全世界的bootloader进行验证，确保非安全世界执行的代码经过授权而没有被篡改过。然后非安全世界的bootloader会加载非安全世界的OS，完成整个系统的启动。
在非安全系统的bootloader加载OS时，仍然需要安全世界对OS的代码进行验证，确保没有被篡改。
图7是典型的TrustZone芯片的启动流程：
图7. 典型的TruestZone芯片启动流程
整个启动流程跟目前博通平台的安全启动原理基本一致，上电后安全芯片先启动，然后校验主芯片的bootloader，接下来bootloader提交系统的OS和文件系统给BSP进行校验，通过后加载主系统，确保主系统是安全的。
从上电复位开始的整个启动过程中，下一级的安全基于上一级的验证，最终依赖于芯片内置的OTP和安全硬件，逐级的验证构成了整个系统的信任链。信任链中的某一个环节被破坏，都会导致整个系统不安全。
3. 各家TrustZone实现
基于安全考虑，各家TrustZone都实行闭源，关于其实现细节的介绍都较少。
网上能找到少许关于高通方案上TrustZone的介绍：
- 安全世界 QSEE (Qualcomm Secure Execution Environment)
- 非安全世界 HLOS (High Level OS)
整个系统的架构如图8：
图8. 高通QSEE系统架构图
4. 其它
-
ARMv8-A架构定义了四个异常等级，分别为EL0到EL3，其中数字越大代表特权(privilege)越大:
- EL0: 无特权模式(unprivileged)
- EL1: 操作系统内核模式(OS kernel mode)
- EL2: 虚拟机监视器模式(Hypervisor mode)
- EL3: TrustZone monitor mode
-
TrustZone设计的相关方
- ARM公司，定义TrustZone并实现硬件设计，TEE，TZAPI等
- 芯片厂家，在具体芯片上实现TrustZone设计，包括三星、高通、MTK、TI、ST、华为等
- 应用提供方，如DRM厂家和安全应用开发商，实现DRM、Playready、DTCP-IP和一些其它安全应用开发和认证
-
Trust OS
TEE环境下也要有一个操作系统，各家都有自己的Trustzone的操作系统，如Trustonic、高通的QSEE、国内的豆荚，还有开源的OPTEE等。在操作系统之上自然要有应用程序，在Trustzone里面我们一般叫TrustApp，当然TEE里面每个TrustApp都在一个沙盒里，互相之间是隔离的。比如说支付，就可以做成一个App（需要注意的是，和Normal World里面的App是两个概念），这个App简单来说就负责用私钥把网上发来的Challenge签个名，而这个签名的动作是需要在Secure World里面做的，避免恶意程序窃取到私钥来伪造签名。
例如支付宝，其实支付宝也是只支持几个Trust OS的。同时，支付宝还定义了一系列标准，用来完成他的行为。
现在的Trust OS大都会遵循GlobalPlatform的规范，这个组织致力于制定统一的Trust OS的API的接口规范，这样一个TrustApp只要用GP API，就可以方便移植到各个不同的TEE操作系统上了。
-
Intel 平台的 SGX
针对可信计算，类似ARM的TrustZone，Intel也针对x86平台提出了自己的安全架构SGX：
Intel® Software Guard Extensions (Intel® SGX)
https://software.intel.com/zh-cn/sgx-sdk
SGX全称Intel Software Guard Extensions，顾名思义，其是对因特尔体系（IA）的一个扩展，用于增强软件的安全性。这种方式并不是识别和隔离平台上的所有恶意软件，而是将合法软件的安全操作封装在一个enclave中，保护其不受恶意软件的攻击，特权或者非特权的软件都无法访问enclave，也就是说，一旦软件和数据位于enclave中，即便操作系统或者和VMM（Hypervisor）也无法影响enclave里面的代码和数据。Enclave的安全边界只包含CPU和它自身。SGX创建的enclave也可以理解为一个可信执行环境TEE（Trusted Execution Environment）。不过其与ARM TrustZone（TZ）还是有一点小区别的，TZ中通过CPU划分为两个隔离环境（安全世界和正常世界），两者之间通过SMC指令通信；而SGX中一个CPU可以运行多个安全enclaves，并发执行亦可。
简单来讲, Intel SGX最关键的优势在于将程序以外的software stack如OS和BIOS都排除在了TCB（Trusted Computing Base）以外。换句话说，就是在容器enclave里的code只信任自己和intel的CPU。
网上有人是这样对比TrustZone和SGX的：
Trustzone默认相信SecureOS，安全世界。SGX仅相信CPU core，通过SGX指令构建enclave容器。简单比喻，TEE是个公用大保险柜，什么东西都装进去，有漏洞的app可能也进去了，而且保险柜钥匙在管理员手上，必须相信管理员。SGX每个app有自己的保险柜，钥匙在自己手上
SGX要进入工业界应用尚需时间，一个重要的问题是现在在intel发行的服务器芯片上还没有SGX，而SGX的重要应用就是在数据中心和云端的应用。
5. TrustZone开源项目
除了各家私有实现外，ARM也有不少开源项目，知名度较高的有：
- Arm Trusted Firmware
- 基于ARMv8-A应用处理器，ARM官方提供了一个开源参考实现BL31。
- https://github.com/ARM-software/arm-trusted-firmware
- Openvirtualization
- 带有一些商业属性的开源项目，部分TEE实现只有商业版支持
- http://www.openvirtualization.org/
- Op-Tee
- Linaro 推出的开源TEE
- https://github.com/OP-TEE
参考资料
