为什么要Intel SGX？
以云环境为例子，云租户会将自己的产品部署在云平台中，但是云平台现在普遍认为是一个不可信的地方，因为可能会有云平台管理者、同一云主机其他租户的恶意攻击，也可能云平台本身存在漏洞，使得黑客轻易的攻击并拿到Ring0权限，这种情况下，云租户就开始担心了。
（就好比我租了房东的一间卧室，我害怕房东、其他租户、陌生人对我房间东张西望，甚至搞破坏。）
与此同时，Intel SGX出现了，它对自己做了一个安全内存Enclave的概念，对安全内存实施权限控制、加密等安全措施，防止别人（Ring0级别的攻击者）非法对安全内存内的敏感数据代码进行机密性、完整性的破坏（个人见解，SGX对可用性并不保障），其中完整性主要通过可信建立Enclave保证。
（就好比，我租了房东卧室后，我对自己卧室的墙进行加固，并且对门加上自己的锁，不让人家偷窥、搞破坏。）
除了云环境，Intel SGX旨在防所有Ring0级别的攻击者（OS、VMM等），服务器中也可以对敏感部分就行加固。开发商下放版权也可以放到客户端的SGX保证版权保护。此外还有对区块链这种分布式客户端的形式就行客户端本地的SGX保护。
Intel SGX尚处于学术讨论
Intel SGX在学术圈属于非常热门的一个点，论文很多，这说明大家感觉Intel SGX的安全特性很有意义，也说明Intel SGX目前也有不少值得探讨的问题存在。
由于Intel SGX会导致应用开发方式的不同，使得Intel SGX很难真正用于实际生产，这里主要指无法将原有的产品直接放到SGX中，这是第一点。第二点，对于未来将开发的产品，由于产品往往依赖于某些库，但是实际中，这些库并没有人将它费劲的搬到SGX中，导致SGX只有Intel维护的标准C/C++库等，并没有丰富的库，导致Enclave内部开发起来也费劲。此外，Enclave内部目前应该只支持C、C++的开发，Python、Java这种个人感觉更适合上层开发的语言目前没有支持。
上述说明SGX是个学术宠儿，但是实际应用中，除非工业界非常感兴趣，不然没有那么多人力物力将不重要的产品搬到SGX中。所以就看产品是否敏感到非用SGX不可。
此外也有Graphene-SGX等能够让传统APP不需要改代码就能跑在SGX中，但是其会引入LibOS等相关内容，使得Enclave内部冗杂，TCB变大；并且效率受影响，SGX本身由于进出Enclave刷新TLB等安全措施导致效率有损耗；兼容性值得考量，个人不是很了解LibOS，但是对LibOS能够提供的兼容性值得考虑。
以我现在观察发现，基于Graphene-SGX等的产品数量貌似不如直接用SGX开发的多，（这个观察不一定准确），一方面是Graphene-SGX知名度不如SGX，一方面是Graphene-SGX出现时间也略晚，还有一方面就是Graphene-SGX某些特性上并不如直接从SGX开发来的高效，稳定。
Intel SGX的好伙伴——ARM上的TrustZone，我们似乎也没有观察到TrustZone也有很普遍的应用，一般还是敏感到需要用到了才不得不用。（观察不一定准确）或许未来又是另一番场景，我便不得而知了，但是可以肯定的是SGX想要广泛应用，必须要SGX支持足够的中间件、库，能让上层便捷的开发。
Intel SGX和可信启动什么关系？
在SGX之前，可信计算中可信启动其实挺火，主要是说从底层Bootloader->BIOS->OS/VMM->APP的一步步递进的可信度量和启动。但是这种模式局限程度高，而且也有人说这限定了就几个大厂的产品满足可信启动的条件，相当于某种垄断。而且这种效率其实也有影响，且TCB大。
SGX主要还是CPU硬件里面强制将某块内存定义为安全内存，并施加硬件级别的访问控制等，这样的话，就不要求整个主机都是可信的，只要SGX所管理的Enclave安全内存是可信就行（包括Enclave代码的可信度量和建立）。
开发者眼中SGX长什么样子？
简单来说SGX就是提供了一个安全内存及其相关。下面稍微讲一下SGX软件栈结构（具体见《SGX软件栈》文档）
总的来说，SGX是划分两个世界的——可信世界和不可信世界。每一个世界中，想要使用SGX的开发都需要开发哪一个世界的代码，一般来说，不可信世界开发非敏感代码（称为APP，另一种理解就是APP也包含Enclave，这样为了区分，就把不可信的叫做APP），可信世界开发敏感代码（Enclave），或者说敏感代码移入了可信世界。
既然有了两个世界，他们之间的连接就需要有一个叫做桥函数的东西，ECALL桥能让APP可以调用桥函数间接调用Enclave中写好的API函数。反向的有个叫OCALL桥的东西。桥函数上承载着两个世界间传递的参数，而且ECALL中，Enclave并不信任APP传给Enclave的ECALL参数，所以需要参数的消毒检查。OCALL有点类似。
既然要开发程序，就要用到SDK（我这里是把可信Enclave使用的SDK称为SDK，这也符合Intel的叫法，另一种理解是SDK包括给不可信APP使用的PSW、给可信Enclave使用的SDK、桥函数）和PSW，这两个都是Intel提供的（linux下见github.com/intel/linux-sgx）。由于Enclave要保证自己内部开发的函数尽可能不会离开Enclave，所以Enclave内部用的SDK都是用静态库链接，除非万不得已，比如系统调用等，那么就得同OCALL桥到不可信世界完成任务。然后顶多是启发式的对OCALL返回值进行检查（而且目前Intel并无消毒检查，除非Enclave开发者自己做检查）。
PSW、SDK一部分功能是用于我们传统的那种为了具有某个功能而开发的函数，还有一部分是对CPU提供的SGX功能指令的包装，主要用于SGX特性的支持，为了让你真正和CPU沟通，并获得SGX特性支持。SGX特性是通过CPU向外面提供Ring0指令和Ring3指令，其中Ring0指令ENCLS主要有一些比如创建Enclave这种生命周期管理、页权限管理的指令。Ring3指令ENCLU主要是让控制流能够在两个世界之间流动，比如进出Enclave这种。
这一块的细节可以看《SGX软件栈》。
SGX访问控制是什么？
SGX访问控制是说对Enclave安全内存进行访问控制，不能让攻击者非法访问敏感内存。这主要还是通过CPU内部实现的。有SGX特性CPU能够让不可信APP只有满足进入它的Enclave的条件时才能放行，而且Enclave A和Enclave B之间是互相不可访问的。这种逻辑是CPU里面的EPCM和内存RAM中被CPU定义为EPC里面的SECS结构体、TCS结构体这些单元连动完成的。
《SGX技术的分析和研究》有介绍具体有哪几则访问控制。
MEE与SGX EPC内存加密
EPC，Enclave Page Cache，是被加密的安全内存页，由MEE加密。
MEE是Memory Encrypt Engine,内存加密引擎，会对从CPU缓存、寄存器之类的地方往其他如内存（比如EPC）、硬盘运输之前都加密，因此在内存、硬盘的敏感数据都是加密的。
这种好处就是能够抗总线攻击，防止攻击者直接物理连接总线窃取敏感数据。劣势，就是或多或少会有加密导致效率的影响，虽然说MEE已经是一个专门的用来加密的模块。
CPU里面SGX长什么样子？
这张图主要是讲SGX初始化过程的，也可以拿来讲解CPU里面多了哪些部件。下面中间RAM这个是内存，内存里面一部分EPC就是存放Enclave的安全内存池，里面有多个安全内存页，每个Enclave按需从这里拿取Enclave安全内存页。
最左下角EPCM（Enclave Page Cache Map）是一个安全内存管控的内置微架构结构体（internal micro-architecture structure ），会由PMH硬件模块进行查EPCM，进行访问控制。PMH和EPCM主管对EPC的访问控制，会依赖SECS、TCS联动判断。
图片右下角就是CPU及其MMU、MEE部件，MMU是传统的地址翻译部件，MEE是说SGX能够做到在EPC中的敏感数据能够明文存在（因为有访问控制，不担心被偷窥），但是EPC中的数据一旦会转到普通硬盘中的（由于EPC大小一般是256M，因此会出现换入换出到硬盘的情况），那么MEE就加密那个明文，只让密文存在于硬盘中。其实MEE不单单是对换入换出到硬盘就行加密，它对任何离开CPU安全边界的明文都进行加密。
最左上角是Enclave代码，这里代表的意思是Enclave代码已经放到了EPC中，然后图片上讲原来在RAM的EPC中的Enclave，单独画出到外面来，它本质是存在于EPC中的。
上面这个APP和Enclave代码是一个二进制文件，最终会被加载到内存的普通内存（APP部分代码）和安全内存中（Enclave部分代码）。
中间OS是在Enclave启动过程中（从无到有），完成对安全内存页申请，代码复制进安全内存页等一系列操作的管理（《SGX软件栈》文档中有专门讲这个）。我之前说了OS是不可信的，所以通过OS启动Enclave会需要一些额外的措施：Architectural Enclave这个特殊的Enclave（由Intel签名并启动起来的Enclave）会对Enclave的完整性进行签名保证，Enclave被OS启动过程中，相应的启动过程的度量会放在EPC的SECS中，最后会对AE签名的那个度量值比对，为了防止OS对Enclave启动过程中做小动作。
总结一下，CPU本身扩充了很多硬件指令，可以分为两大类ENCLS、ENCLU。上图可以看到CPU所增加的硬件部件，有MEE、PMH（查EPCM）、Intel ME（粗粗了解到它提供可信输入和可信时间）（其他暂且没想到，似乎还有）。
SGX初始化过程大概就是建立时候申请安全内存页，然后将Enclave代码放进去，并且度量建立过程是否可靠。（细节见《SGX软件栈》）
有Enclave的APP的虚拟地址空间长什么样？
APP依然还是那个APP，有着常见的虚拟地址空间（比如4G，32位地址下），然后其中有一整块，比如0X700-0X800（通过观察一般都是高地址，这里只是随便写了）是给Enclave的，因为Enclave是一个.so动态库链接给APP的，Enclave虚拟地址的起始地址依赖于ALSR地址空间随机化给定。
那我们假设访问某个Enclave函数时，我们用的这个函数的虚拟地址（和正常虚拟地址空间里面调用函数一样），然后会经过MMU的虚实地址转换，变成物理地址，这个物理地址会指向EPC，前面讲了EPC是RAM中的一部分（而且是靠前的一部分，存在于PRM中，由BIOS和范围寄存器来决定EPC的大小），所以EPC也是有物理地址的，这也很正常。物理地址拿到后，想要访问EPC物理页，那么请先经过EPCM的访问控制检查。如果通过了，那么IP寄存器就会给到那个Enclave函数了。
SGX目录、文件初体验
和传统应用开发不同，上图可以看到APP、Enclave是分开编写的。命名倒是无所谓，具体会通过Makefile里面说明把哪些编程Enclave。
此外，通过这个EDL文件可以清楚的看到光是进出Enclave的接口就分开了。一部分trusted括起来的是ECALL用来进入Enclave，untrusted括起来的是OCALL，用来离开Enclave。
SGX和它的小伙伴
要知道可信执行环境不止Intel SGX一家，所以很多思想可能值得借鉴的地方，并且，应该是能够以可信执行环境一个更高的高度来看待这些应用攻防的问题。
硬件比如还有TrustZone，软件有Virtual Ghost、SP3、Overshadow、InkTag、CHAOS、AppShield，他们都或多或少有类似Enclave的可信执行环境的概念。
SHIELDING SOFTWARE FROM PRIVILEGED SIDE-CHANNEL ATTACKS(SEC’18)这篇是关于Virtual Ghost的工作。它做了两个工作。第一，针对已有的页表侧信道，它的做法是将页表机制由Virtual Ghost内部来完成，OS所保管的Direct Map中对于Virtual Ghost内部安全有用户空间的映射被删除。第二，针对LLC侧信道，利用Intel Cache Allocation Technology，从硬件层面对LLC实施隔离，不让OS窥探Virtual Ghost内部的存放于LLC中隐私。Intel CAT技术是Intel RDT的子模块，我目前感觉和SGX一样是向用户态提供Ring3指令用于CPU特性管理（可能存在错误）。
接下来我们讲讲现在有哪些SGX的研究了。分类方法主要依赖于CCS’17中，关于SGX的三篇综述
