使用命令行，发现 curl 某个请求时报错：
ERROR: The certificate of ‘xxx’ is not trusted.
ERROR: The certificate of ‘xxx’ has expired.
这就奇怪了，只在某个服务器上才有问题，其他服务器又没有问题。遂把证书抓下来看看啥情况。
openssl s_client -connect {HOSTNAME}:{PORT} -showcerts
# 例如：
openssl s_client -connect blog.kelu.org:443 -showcerts
即可下载证书。
另外如果 curl 可以使用 -k 跳过证书验证。
对官方的文档有点心累了。一个简单的需求硬是扣扣搜搜分成多个步骤，不一次性给出来。
索性记录现成的方案。
相关镜像如果在国内无法下载，可以在这里参考镜像名，用国外服务器 docker save 再 docker load加载到本地。
# Copyright 2017 The Kubernetes Authors.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
apiVersion: v1
kind: Namespace
metadata:
name: kubernetes-dashboard
---
apiVersion: v1
kind: ServiceAccount
metadata:
labels:
k8s-app: kubernetes-dashboard
name: kubernetes-dashboard
namespace: kubernetes-dashboard
---
kind: Service
apiVersion: v1
metadata:
labels:
k8s-app: kubernetes-dashboard
name: kubernetes-dashboard-external
namespace: kubernetes-dashboard
spec:
ports:
- port: 9090
targetPort: 9090
selector:
k8s-app: kubernetes-dashboard
---
kind: Service
apiVersion: v1
metadata:
labels:
k8s-app: kubernetes-dashboard
name: kubernetes-dashboard-external-test
namespace: kubernetes-dashboard
spec:
ports:
- port: 9090
targetPort: 9090
nodePort: 30000
type: NodePort
selector:
k8s-app: kubernetes-dashboard
---
apiVersion: v1
kind: Secret
metadata:
labels:
k8s-app: kubernetes-dashboard
name: kubernetes-dashboard-certs
namespace: kubernetes-dashboard
type: Opaque
---
apiVersion: v1
kind: Secret
metadata:
labels:
k8s-app: kubernetes-dashboard
name: kubernetes-dashboard-csrf
namespace: kubernetes-dashboard
type: Opaque
data:
csrf: ""
---
apiVersion: v1
kind: Secret
metadata:
labels:
k8s-app: kubernetes-dashboard
name: kubernetes-dashboard-key-holder
namespace: kubernetes-dashboard
type: Opaque
---
kind: ConfigMap
apiVersion: v1
metadata:
labels:
k8s-app: kubernetes-dashboard
name: kubernetes-dashboard-settings
namespace: kubernetes-dashboard
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: kubernetes-dashboard-v2
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- kind: ServiceAccount
name: kubernetes-dashboard
namespace: kubernetes-dashboard
---
kind: Deployment
apiVersion: apps/v1
metadata:
labels:
k8s-app: kubernetes-dashboard
name: kubernetes-dashboard
namespace: kubernetes-dashboard
spec:
replicas: 1
revisionHistoryLimit: 10
selector:
matchLabels:
k8s-app: kubernetes-dashboard
template:
metadata:
labels:
k8s-app: kubernetes-dashboard
spec:
containers:
- name: kubernetes-dashboard
image: k8s.gcr.io/dashboard:v2.0.0-rc5
ports:
- containerPort: 9090
protocol: TCP
args:
- --namespace=kubernetes-dashboard
# Uncomment the following line to manually specify Kubernetes API server Host
# If not specified, Dashboard will attempt to auto discover the API server and connect
# to it. Uncomment only if the default does not work.
# - --apiserver-host=http://my-address:port
volumeMounts:
- name: kubernetes-dashboard-certs
mountPath: /certs
# Create on-disk volume to store exec logs
- mountPath: /tmp
name: tmp-volume
livenessProbe:
httpGet:
scheme: HTTP
path: /
port: 9090
initialDelaySeconds: 30
timeoutSeconds: 30
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
runAsUser: 1001
runAsGroup: 2001
volumes:
- name: kubernetes-dashboard-certs
secret:
secretName: kubernetes-dashboard-certs
- name: tmp-volume
emptyDir: {}
serviceAccountName: kubernetes-dashboard
nodeSelector:
"beta.kubernetes.io/os": linux
# Comment the following tolerations if Dashboard must not be deployed on master
tolerations:
- key: node-role.kubernetes.io/master
effect: NoSchedule
---
kind: Service
apiVersion: v1
metadata:
labels:
k8s-app: dashboard-metrics-scraper
name: dashboard-metrics-scraper
namespace: kubernetes-dashboard
spec:
ports:
- port: 8000
targetPort: 8000
selector:
k8s-app: dashboard-metrics-scraper
---
kind: Deployment
apiVersion: apps/v1
metadata:
labels:
k8s-app: dashboard-metrics-scraper
name: dashboard-metrics-scraper
namespace: kubernetes-dashboard
spec:
replicas: 1
revisionHistoryLimit: 10
selector:
matchLabels:
k8s-app: dashboard-metrics-scraper
template:
metadata:
labels:
k8s-app: dashboard-metrics-scraper
annotations:
seccomp.security.alpha.kubernetes.io/pod: 'runtime/default'
spec:
containers:
- name: dashboard-metrics-scraper
image: k8s.gcr.io/metrics-scraper:v1.0.3
ports:
- containerPort: 8000
protocol: TCP
livenessProbe:
httpGet:
scheme: HTTP
path: /
port: 8000
initialDelaySeconds: 30
timeoutSeconds: 30
volumeMounts:
- mountPath: /tmp
name: tmp-volume
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
runAsUser: 1001
runAsGroup: 2001
serviceAccountName: kubernetes-dashboard
nodeSelector:
"beta.kubernetes.io/os": linux
# Comment the following tolerations if Dashboard must not be deployed on master
tolerations:
- key: node-role.kubernetes.io/master
effect: NoSchedule
volumes:
- name: tmp-volume
emptyDir: {}
我在安装on my zsh时报错
fatal: remote error:
The unauthenticated git protocol on port 9418 is no longer supported.
Please see https://github.blog/2021-09-01-improving-git-protocol-security-github/ for more information.
根据官方博客，github升级了他们的安全机制，不再支持端口 9418 上未经身份验证的 git 协议错误。
一 使用https:替换git:
git config --global url."https://".insteadOf git://
二 修改 git://github.com/
将
git://github.com/...
替换成
github:......
大家好，我是今天的讲师田洪亮（花名：樱桃），蚂蚁集团技术专家，也是 Occlum 开源负责人。今天我和大家分享一下如何使用 Occlum 的轻松开发机密计算应用以及 Occlum 技术架构和特色。
云计算、大数据、人工智能，我们正处在一个数据爆炸的时代。如何能够在享受和利用海量数据所产生的价值的同时，保证数据的安全和用户的隐私呢？这无异是一个用户、企业和监管部门共同关注的问题。
近年来兴起的机密计算（Confidential Computing），正是为了解决这个问题而来。利用可信执行环境（Trusted Execution Environments，简称 TEE）技术，机密计算使得数据始终保持加密和强隔离状态，从而确保了用户数据的安全和隐私。机密计算可以解决诸多应用场景中“信任”难题，比如多个不互信组织之间的数据融合与联合分析、区块链上的智能合约的机密性保护、公有云平台对外部或内部攻击的防御、高敏感信息（比如密码学材料、医疗档案等）的安全保护等等。
但是，机密计算底层依赖的 TEE 技术——比如目前最成熟的云端 TEE 技术 Intel SGX——也带来了额外的功能限制和兼容问题。这使得机密计算的开发者面领一个巨大的阻碍：应用开发难。
在本文中，我们会首先分析当前 SGX 应用开发者会遇到的各种挑战和痛点，然后介绍蚂蚁集团自研的开源 TEE OS 系统 Occlum 如何大幅降低 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，开发者会遭遇下面的开发困境：
上述困境使得为 SGX 开发应用成为一件十分痛苦的事，制约了 SGX 和机密计算的普及度和接受度。
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 做应用移植。
在了解了 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 还有三个主要特色：
下面的传送门提供了更多资料：
8 月 26 日，我们发起了第 6 期 SIG Cloud-Provider-Alibaba 网研会直播。本次直播主要介绍了机密计算的概况， InclavareContainers 开源项目架构、已支持的功能和迭代计划，以及阿里云 ACK-TEE 的发展现状和规划。
本文汇集了此次直播完整视频回顾及资料下载，并整理了直播过程中收集的问题和解答，希望能够对大家有所帮助~阿里巴巴云原生公众号后台回复“826”即可下载相关 PPT。
直播视频回顾链接：https://v.qq.com/x/page/z3143a6agsg.html
Portworx and Aqua Security 发布的《2019 容器接受度调研》报告显示，安全性成为了用户使用容器技术和业务上云面临的最大挑战，其中数据安全问题最为突出；根据 Risk Based Security 发布的数据泄露报告显示，2019 年数据泄露事件发生的数量和泄露的数据量与 2018 年相比均增加了 50%+。
数据在整个生命周期有三种状态：At-Rest（静态）、In-Transit（传输中）和 In-Use（使用中）。
机密计算联盟给机密计算的定义是：机密计算是在一个基于硬件的可信执行环境（TEE）中保护数据执行计算。
机密计算的核心功能有：
在 2019 年 Gartner 的《计算基础设施成熟度曲线》中把机密计算也列入其中，虽然还处在早起阶段，这也说明机密计算开始逐步进入大家的视野并得到重视。
在 2020 年 Gartner的《云厂商本地安全解决方案比较》中，阿里云在 Trusted execution enviorments 中拿到一个 H，是因为 2020 年年初阿里云容器服务发布了机密计算产品 ACK-TEE，更多参考链接。
机密计算旨在保护敏感的代码和数据。业务场景有：区块链、秘钥管理、金融、AI、多方计算、数据租赁、边缘计算等。
以多方计算为例，不同用户或厂商之间相互共享数据以便计算挖掘出更大的数据经济价值，但不想把自己的数据泄露给对方。机密计算可以保护共享数据运行在受硬件保护的可信执行环境中，数据在内存中是加密的，从而保证数据不会被泄露。
除了机密计算外，还有一个与安全相关的概念-安全容器。阿里云在安全容器和机密计算领域都有布局，虽然二者都与安全相关，但它们的定位和应用场景是不同的。
安全容器的定位是隔离，把恶意应用隔离起来，防止它出去对其他应用搞破坏。主要的应用场景有三类：
机密计算的定位是保护，保护应用不会被其他恶意应用进来窃取数据和搞破坏。应用场景是保护敏感代码和数据。
支持 TEE 的硬件平台主要有 3 个：Intel SGX、ARM TrustZone 和 AMD SEV，它们有不同的应用场景和实现方式：
阿里云 ACK-TEE 和开源项目 Inclavare Containers 都是基于 Intel SGX 实现的机密计算。
按照普通方式部署敏感应用，应用会依赖操作系统、VMM、硬件甚至是云厂商，TCB 非常大，面临的攻击面也非常大。只要 TCB 中只要有一处遭到攻击，应用都有数据泄露和破坏的风险。
而把敏感应用部署在 Intel SGX 的 TEE 中，TCB 只有 CPU 和 TEE 本身。一方面攻击面变得很小，另一方面 TEE 的安全机制也会使应用更安全。
Intel SGX 把应用分成了可信区和不可信区。用户可通过在 EDL（Enclave Definition Language）中定义可信区和不可信区以及用到的函数。这些函数用户可信区和不可信区之间的通信，分为 ECALL 和 OCALL。ECALL 用于不可信区访问可信区的数据，OCALL 用于可信区访问不可信区的数据。
基于 Intel SGX 的可信应用开发和使用流程如下：
Inclavare，是 Enclave 一词的拉丁语词源，读音是 [ˈinklɑveə]。Enclave 指的是一种受保护的执行环境，能为其中的敏感和机密数据提供基于密钥学算法的强安全隔离，阻止不可信的实体访问用户的数字资产。
Inclavare Containers 是由阿里云操作系统安全团队和阿里云云原生容器服务团队主导，并联合了阿里经济体内多个研发团队（蚂蚁安全计算团队、云安全团队、语言 runtime 团队等）共同研发的面向机密计算场景的开源容器运行时技术栈。
当前机密计算在云原生场景中提供的技术，有很多缺陷和不足：
由于以上原因，非常不利用机密计算技术的普及和应用。而 Inclavare Containers 目的就是为业界提供一款面向机密计算领域的开源容器运行时引擎和安全架构，其价值在于：
在介绍 Inclavare Containers 架构之前，先介绍一下架构中各个组件的作用：
Inclavare Containers 的工作流程如下：
总结下来，Inclavare Containers 的特点有：
shim-rune 包含两部分 Core 和 Carrier，它们的作用分别是：
shim-rune 的工作流程为：
Inclavare Containers 支持客户端签名和服务端签名两种工作方式，两种工作方式的差异如下：
相比客户端签名，服务端签名优点如下：
注意：每种 LibOS 对普通镜像也有一定要求，比如 Occlum 只支持 musl libc 而不支持 glibc，所以 glibc 应用需要改造为 musl libc 应用之后才能在 Inclavare Containers 中运行起来。
Inclavare Containers 项目是由多个团队共建合作而成的，各组件作用和团队分工如下：
Inclavare Containers 是业界首个面向云原生的机密计算场景下的开源容器运行时技术栈，被阿里巴巴开源委员会评为重点开源项目。并且已经加入到官方机密计算 OCIRuntime 参考实现列表。
目前支持的功能有：
该项目每个月月底进行一次发布，面向社区提供 CentOS 和 Ubuntu 的 binary release，并对内提供 AliyunLinux 发行版本。
ACK-TEE 于 2019 年 9 月立项
功能：
合作团队：阿里云容器服务团队、操作系统内核团队、云安全团队、蚂蚁安全团队和运行时语言团队
定位：云原生机密计算容器平台
使命：让天下没有难用的机密计算
产品原则：可信安全、易开发交付、标准开放、云原生
ACK-TEE 1.0 于 2020 年 1 月份上线
目标用户群体：原生 SGX 用户
全新 K8s 托管集群形态：机密计算专用集群，支持 Intel SGX1。
复用 Managed K8s 已有能力，包括各种云产品集成，K8s 集群运维能力，降低 K8s 集群的运维复杂度；
支持 EPC 加密内存的管理和调度，降低用户使用 SGX 设备的复杂度。
ACK-TEE2.0 计划在 2020 下半年上线
功能：支持原生应用在 TEE 中运行起来
目标用户：没有掌握机密计算技术但有数据安全需求的用户
方案
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的介绍，主要有：
- 网站 https://developer.arm.com/technologies/trustzone
- 文档 Building a Secure System using TrustZone Technology
事实上，前面多篇文章的细节也来源于官方文档。 本人不保留本文的所有权，欢迎转载本文，让更多的人来了解TrustZone。由于不想再次以类似 《TrustZone原理介绍》 一类作为标题，但又不知道以什么作为标题贴切，所以随手用了现在标题党的套路，抱歉。
在介绍TrustZone前有必要简单回顾下目前的一些安全手段。
CPU通过内存映射手段给每个进程营造一个单独的地址空间来隔离多个进程的代码和数据，通过内核空间和用户空间不同的特权级来隔离操作系统和用户进程的代码和数据。但由于内存中的代码和数据都是明文，容易被同处于内存中的其它应用偷窥，因此出现了扩展的安全模块，应用将加密数据送往安全模块，由安全模块处理完后再返回结果给相应的应用。
很多消费电子设备都使用扩展的安全模块来确保数据安全，目前常见的方式有：
外部挂接硬件安全模块
数据的处理交由外部的安全模块实现，这些模块能够保护自己的资源和密钥等数据的安全，如SIM卡、各种智能卡或连接到外部的硬件加解密模块等，但其同主芯片的通信线路暴露在外部，容易被监听破解。另外，通信的速率比较低。
内部集成硬件安全模块
将外部安全模块的功能集成到芯片内，因此一个芯片上至少有两个核：一个普通核和一个安全核。优点是核与核之间的通信在芯片内部实现，不再暴露在外面。缺点是核之间的通信速度仍然较低，而且单独的安全核性能有限，还会会占用SoC面积，成本较高。
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实现。
其中主要的组件有：
除了以上列出的组件外，还有诸如 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）是跨行业的国际标准组织，致力于开发、制定并发布安全芯片的技术标准，以促进多应用产业环境的管理 及其安全、可互操作的业务部署。目标是创建一个标准化的基础架构, 加快安全应用程序及其关联资源的部署，如数据和密钥，同时保护安全应用程序及其关联资源免受软件方面的攻击。
以下主要从TrustZone的总线设计，CPU设计(包括处理器模型、内存模型和中断模型)和安全隔离机制来介绍TrustZone的设计和工作原理。
设计上，TrustZone 在系统总线上针对每一个信道的读写增加了一个额外的控制信号位，这个控制位叫做Non-Secure或者NS位，是AMBA3 AXI总线针对TrustZone作出的最重要、最核心的扩展设计。
这个控制信号针对读和写分别叫做ARPORT[1]和AWPORT[1]：
总线上的所有主设备(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。
TrustZone中，每个物理处理器核被虚拟为一个安全核(Secure)和一个非安全核(Non-Secure)，安全核运行安全世界的代码，非安全核运行除安全世界外的其它代码。由于安全世界和非安全世界的代码采用时间片机制轮流运行在同一个物理核上，相应的节省了一个物理处理器核。
多核处理器上，也有建议说让将某一个或几个核指定为安全专用核，只运行安全系统代码来构建安全世界，其余核运行非安全代码，暂不清楚目前有哪些平台采用这个实现。
图3中，系统有4个物理核，每个又分为两个虚拟核（安全核和非安全核）的情况：
图3. 多核处理器上的安全核和非安全核
MMU是一种硬件电路，它包含两类部件，一类是分段部件，一类是分页部件，对应于内存管理的分段机制和分页机制。分段机制把一个逻辑地址转换为线性地址；接着，分页机制把一个线性地址转换为物理地址。
当CPU访问一个虚拟地址时，这个虚地址被送到MMU翻译，硬件首先把它和TLB中的所有条目同时(并行地)进行比较，如果它的虚页号在TLB中，并且访问没有违反保护位，它的页面会直接从TLB中取出而不去访问页表，从而提高地址转换的效率。
安全世界和非安全世界都有自己的虚拟MMU，各自管理物理地址的映射。实际上只是两个世界都有一份TTBR0、TTBR1、TTBCR寄存器，因此就会对应两个MMU表。
尽管MMU有两套，但TBL缓存硬件上只有一套，因此TBL对于两个世界来说是共享的，其通过NS位来标志其每一项具体属于哪一个世界。这样在两个世界间进行切换时不再需要重新刷新TLB，提高执行效率。
对于TLB共享并不是硬性规定的，部分芯片在两个世界间切换时可能通过硬件部分或全部刷新TLB。
同TLB类似，硬件上两个世界共享一套Cache，具体的Cache数据属于哪一个世界也由其NS位指定，在世界间切换也不需要刷新Cache。
基于TrustZone的处理器有三套异常向量表：
与之前非TrustZone的处理器不同的是，这三套中断向量表的基地址在运行时可以通过CP15的寄存器VBAR(Vector Base Address Register)进行修改。
复位时，安全世界的中断向量表由处理器的输入信号VINITHI决定，没有设置时为0x00000000，有设置时为0xFFFF0000；非安全世界和Monitor模式的中断向量表默认没有设置，需要通过软件设置后才能使用。
默认情况下，IRQ和FIQ异常发生后系统直接进入Monitor模式，由于IRQ是绝大多数环境下最常见的中断源，因此ARM建议配置IRQ作为非安全世界的中断源，FIQ作为安全世界的中断源。这样配置有两个优点：
将IRQ设置为非安全世界的中断源时系统IRQ的切换见图4：
图4. IRQ作为非安全世界的中断源
基于TrustZone的系统有三种状态，安全世界、非安全世界和用于二者切换的Monitor Mode。
协处理器CP15的寄存器SCR(Secure Configuration Register)有一个NS位用于指示当前处理器位于哪一个世界，该寄存器在非安全世界是不能访问的。当CPU处于Monitor Mode时，无论NS位是0还是1，处理器都是在安全世界运行代码。因此Monitor Mode下总是安全世界，但如果此时NS为1，访问CP15的其它寄存器获取到的是其在非安全世界的值。
处理器从非安全世界进入Monitor Mode的操作由系统严格控制，而且所有这些操作在Monitor Mode看来都属于异常。 从非安全世界到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. 安全世界和非安全世界之间的切换
除了CPU执行时实行安全世界和非安全世界的隔离外，AMBA3 AXI总线提供了外设隔离的基础。
这里的内存指外部的DDR和片上的ROM以及SRAM，其隔离和保护通过总线组件TZASC和TZMA的设置来实现。
外设上，基于APB总线的设备不支持AXI总线的NS控制信号，所以AXI到APB总线需要AXI-to-APB bridge设备连接，除此之外，还需要TZPC (TrustZone Protection Controller) 来向APB总线上的设备提供类似AXI上的NS控制信号。
由于TZPC可以在运行时动态设置，这就决定了外设的安全特性是动态变化的，例如键盘平时可以作为非安全的输入设备，在输入密码时可以配置为安全设备，只允许安全世界访问。
整个系统内存和外设隔离机制示意图见图6.
图6. 系统内存和外设隔离机制示意图
此图来源于网上，实际上TZPC还连接到片内的ROM/RAM设备上，用于配置片上存储的安全区域。
AMBA3 AXI总线机制隔离出安全世界和非安全世界，但这是系统启动之后的事情。如何确保系统本身是安全的呢？这就涉及到系统启动的过程。
系统上电复位后，先从安全世界开始执行。安全世界会对非安全世界的bootloader进行验证，确保非安全世界执行的代码经过授权而没有被篡改过。然后非安全世界的bootloader会加载非安全世界的OS，完成整个系统的启动。
在非安全系统的bootloader加载OS时，仍然需要安全世界对OS的代码进行验证，确保没有被篡改。
图7是典型的TrustZone芯片的启动流程：
图7. 典型的TruestZone芯片启动流程
整个启动流程跟目前博通平台的安全启动原理基本一致，上电后安全芯片先启动，然后校验主芯片的bootloader，接下来bootloader提交系统的OS和文件系统给BSP进行校验，通过后加载主系统，确保主系统是安全的。
从上电复位开始的整个启动过程中，下一级的安全基于上一级的验证，最终依赖于芯片内置的OTP和安全硬件，逐级的验证构成了整个系统的信任链。信任链中的某一个环节被破坏，都会导致整个系统不安全。
基于安全考虑，各家TrustZone都实行闭源，关于其实现细节的介绍都较少。
网上能找到少许关于高通方案上TrustZone的介绍：
整个系统的架构如图8：
图8. 高通QSEE系统架构图
ARMv8-A架构定义了四个异常等级，分别为EL0到EL3，其中数字越大代表特权(privilege)越大:
TrustZone设计的相关方
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的重要应用就是在数据中心和云端的应用。
除了各家私有实现外，ARM也有不少开源项目，知名度较高的有：
云厂商的主机实例一般默认使用DHCP（动态主机设置协议，Dynamic Host Configuration Protocol）为弹性网卡自动分配IP地址，并获得IP地址租约到期时间。正常情况下，Linux 实例的dhclient进程会定期向DHCP服务器更新租约到期时间，以确保实例IP地址的可用性。以下情况可能引发Linux实例的DHCP服务出现异常，导致实例网络不通：
dhclient进程未运行网卡配置文件和操作系统有关，这里暂不展开了，只讲dhclient的内容。在Linux实例中执行以下命令，检查对应网卡的dhclient进程运行状态。我的网卡名叫eth0。
ps aux | grep dhclient | grep eth0
系统无返回结果，说明dhclient进程未运行。执行如下命令启动：
dhclient eth0
# 或者
ifup eth0