或多或少大家在读本文之前都听说过Intel SGX如何如何厉害云云，我想说的是SGX其实只解决了可信计算的一小部分，距离大多数人脑中的理想还很远。
简单的说 Intel SGX 试图在用户相信Intel的前提下保证：
- 编译生成的 enclave.sign.so 是目前正在运行的这个 enclave.sign.so
- 这个 SGX enclave 里的 secret 不会通过非 side channel 泄露出去
- 这个 enclave 具体跑在哪个 platform (=CPU+mb) 上是不可知的
但是这不包括：
- 我写下的代码是正在运行的代码。这需要一个诚实的编译器，和许多诚实的库。不是SGX的事。
- SGX enclave会一直工作。因为它毕竟还是依赖于内核分配资源给他。内核不分配内存，线程被杀死这种事一旦发生，enclave也会停下来的。
- 保证 enclave 拿到的“外界输入”都是正确的。试想一下，如果把一个python解释器放进SGX enclave，在解释执行的python源代码中写下
import os的时候会发生什么？Python解释器会去文件系统中找到os并把它读进内存。然而SGX的信任边界并不能保证这个读进来的os是被期待的os！任何攻击者都可以篡改这个os导致在enclave里执行恶意逻辑！（那些在enclave里把syscall包一层从而支持任意程序的在我看来都是“使用SGX”但是没有被SGX保护的典型）。
SGX的一个典型应用就是做多方安全计算（Secure Multiparty Computing）。举例如百万富翁问题。借助SGX可以构造一个可信的裁判来解决：
- 两个大富翁首先都得相信Intel。
- 两个大富翁需要共同review这个裁判enclave的代码，取得共识，都认为这个enclave是公正的。
- 用两人都认可的编译环境生成enclave.sign.so。
- 把这个enclave在任何SGX执行环境上跑起来。
- 两人分别remote attest这个跑起来的enclave，验证其report是否完全满足安全需求。
- 分别把自己的财产数通过安全的信道传给enclave，enclave做出判断，返回给两人结果。
看起来很美，但实际上坑还是挺多的……后面再具体分析吧。
为了支持这个可信计算环境，Intel做了非常多工作的，大概包括（不限于）：
- 一个精巧的 Memory Encryption Engine，保证了 enclave 内的数据只有 enclave 自身才能访问明文。出了CPU就是密文，就算直接截胡memory bus也听不到有意义的数据。
- 一套基于 EPID 的组签名机制，保证 platform (=CPU+mb)的匿名性。
- remote attestation的IAS支持。
- 一套 trusted/untrusted 的基础库。
- 论坛
纵使世界上有那么多关于SGX的论文、分析，我想说的是，不自己看一遍Intel官方的手册、文档和读SDK、driver代码的话，是很难理解SGX实现起来是怎么一回事的。但是这些东西太无聊，读着读着就很容易——放弃了！秘而不宣的东西很多都藏在代码和官方文档里，还是得耐着性子看一遍。我会尽量在这些blog里提供一些其他地方没有的分析——如果还没放弃的话。
无论如何——我建议每个人都亲自读 Intel SGX Developer Guide（2.2版本)。这份40页的小书还是蛮有意思，可以体会体会Intel是怎么个口径的。
- 力推 Platform Embedded Security Technology Revealed。如果对可信计算没概念的话，耐着性子读完这本书会很有帮助！
- Intel SGX 主页
- Intel SGX SDK 主页
- Intel Open Source 01.org 上的 SGX for linux 主页 一般来讲这里更新最快
- Intel 官方的 linux-sgx-sdk
- Intel 官方的 linux-sgx-driver
- 一份 Remote Attestation 实现 linux-sgx-remoteattestation
- 一百多页的 Intel SGX Explained 基本读不完就放弃了
- SGX-hardware 哪些CPU/主板/云厂商提供SGX支持，可以参考。也包含一个检测sgx是否支持/开启的小程序。