Intel SGX Explained

这篇文章翻译自Intel SGX Explained。

SGX新增

新增CPU指令

指令	解释
EREPORT	发起签名进程？身份认证，签名
EGETKEY	产生认证秘钥

特殊的enclave

特定enclave	解释
Quoting Enclave	执行签名进程，能够访问SGX认证秘钥，签名函数等在该enclave里
Provisioning enclave	产生认证秘钥

新增硬件结构

硬件结构	解释
EPCM	enclave page cache map，用于页面分配的安全检查
SCES
EPC

Abstract

Intel的软件保护扩展（SGX）是Intel架构的一组扩展，其目标是对计算平台上的敏感计算提供完整性和机密性保证，其中计算平台上的所有特权软件（kernel，hypervisor等）可能是恶意的。
本文分析了英特尔SGX，基于介绍它的3篇论文[14,79,139]，在英特尔软件开发者手册[101]（取代SGX手册[95,99]），在ISCA 2015教程[103]，以及两项专利[110,138]。我们使用论文、参考手册和教程作为主要的数据源，并且只利用专利来填写缺失的信息。

本文没有反映在本文第一版后发表的两篇论文[74,109]中的信息。

本文的贡献是对理解SGX所需的特定架构和微架构细节的总结，关于SGX的公开信息的详细介绍，一系列关于SGX的一些重要但未经文档记录的方面的智能猜测，以及对SGX的安全属性的分析。

第一章 概括

安全远程计算（如图1）是在不可信任方拥有和维护的远程计算机上执行软件的问题，具有一些完整性和机密性保证。在一般情况下，安全的远程计算是一个未解决的问题。完全同态加密[61]解决了有限的计算族的问题，但具有不切实际的性能开销[140]。

英特尔的软件保护扩展（SGX）是一长串可信计算（图2）设计中的最新迭代，旨在通过利用远程计算机中的可信硬件来解决安全的远程计算问题。受信任的硬件建立一个安全的容器和远程计算服务用户将所需的计算量和数据上传到安全容器中。在对数据执行计算时，可信的硬件可以保护数据的机密性和完整性。

SGX依赖于软件认证，就像它的前辈，TPM [71]和TXT [70]一样。认证（图3）向用户证明，她正在与运行在受信任硬件托管的安全容器中的特定软件片段进行通信。

软件认证向远程计算机证明，它正在与由可信平台托管的特定安全容器进行通信。该证明是由该平台的秘密认证密钥产生的认证签名。该签名涵盖了容器的初始状态、远程计算机产生的挑战nonce以及容器产生的消息。（图3表明了DH密钥协商和认证阶段，其中签名私钥是只有可信硬件知道，但是其验证签名的公钥是什么？怎么产生的？）
内容证明和环境证明

证明 是一个证明安全容器内容哈希的 加密签名。因此，远程计算机的所有者可以在安全容器中加载任何软件，但远程计算服务用户将拒绝将其数据加载到安全容器中，当其内容的哈希值不匹配时。

远程计算服务的使用者，即用户根据受信任硬件制造商创建的 背书证书（Endorsement Certificate） 验证用于生成签名的认证密钥（类似于使用公钥证书来验证公钥的合法性，进而验证了该用户的身份，即验证了平台的可信性）。该证书声明，只有受信任的硬件才知道该认证密钥，并且仅用于认证目的。

背书证书（Endorsement Certificate） 是什么？

SGX因为认证所覆盖的代码量从现有的技术中脱颖而出，即使用硬件保护的系统的可信计算基（TCB）。最初的TPM设计所产生的认证覆盖了运行在计算机上的所有软件，而TXT认证则覆盖了VMX [181]虚拟机中的代码。在SGX中，一个飞地enclave（安全容器）只包含计算中的私有数据，以及对其进行操作的代码（TCB）。

例如，可以通过让用户上传加密的图像来实现对机密医疗图像进行图像处理的云服务。用户将把加密密钥发送到运行在飞地内的软件。该飞地将包含解密图像的代码、图像处理算法和加密结果的代码。接收上传的加密图像并存储它们的代码将被留在飞地之外。

启用SGX的处理器通过将飞地的代码和数据与外部环境 隔离 ，包括操作系统和系统总线的硬件设备，来保护飞地内计算的完整性和机密性。与此同时，SGX模型仍然与Intel体系结构中的传统软件分层兼容，即操作系统内核和管理系统管理程序管理计算机的资源。

这项工作讨论了SGX的原始版本，也被称为SGX 1。而SGX 2对于飞地作者来说是非常有用的改进，对于设计和实现的角度来说，这是一个小的增量改进。在了解了SGX 1背后的原理及其安全属性之后，读者应该能够很好地面对英特尔的参考文档，并了解SGX 2所带来的变化。

1.1 SGX简介

SGX留出一个内存区域，称为处理器保留内存（Processor Reserved Memory，PRM，5.1）。CPU保护PRM免受所有非飞地内存访问，包括内核、系统管理程序hypervisor和SMM（2.3）访问，以及来自外设的DMA访问（2.9.1）。

PRM包含飞地页面缓存（Enclave Page Cache，EPC，5.1.1），它由存储飞地代码和数据的4 KB页面组成。该不受信任的系统软件负责将EPC页面分配给飞地。CPU跟踪在飞地页面缓存元数据（Enclave Page Cache Metadata，EPCM，5.1.2）中的每个EPC页面的状态，以确保每个EPC页面恰好属于一个飞地。

一个飞地中的初始代码和数据由不受信任的系统软件加载。在加载阶段（5.3）中，系统软件要求CPU将数据从未受保护的内存（PRM外部）复制到EPC页面中，并将这些页面分配给正在设置的飞地（5.1.2）。由此可见，系统软件已经知道了最初的飞地状态。

在所有飞地的页面加载到EPC后，系统软件要求CPU将飞地标记为初始化（5.3），此时应用软件可以在飞地内运行代码。在初始化一个飞地后，将禁用上述的加载方法。

当加载一个飞地时，其内容会被CPU加密hash。当飞地被初始化时，hash被最终确定，并成为飞地的度量散列（5.6）。

远程方可以通过软件认证过程（5.8）来说服自己它正在与具有特定度量散列的飞地通信，并且在安全环境中运行。

执行流只能通过特殊的CPU指令（5.4）进入一个飞地，这类似于从用户模式切换到内核模式的机制。飞地执行总是发生在保护模式下，在环3，并使用由操作系统内核和管理程序设置的地址转换。

为了避免泄漏私有数据，正在执行飞地代码的CPU不会直接服务于中断、故障（例如，页面故障）或VM退出。相反，CPU首先执行一个异步飞地退出（5.4.3），从飞地代码切换到环3代码，然后为中断、故障或VM退出提供服务。CPU通过将CPU状态保存到飞地内的预定义区域来执行AEX，并将控制转移到飞地外的预先指定的指令，用合成值替换CPU寄存器。

EPC页面的分配委托给操作系统内核（或管理程序）。操作系统通过特殊的环0 CPU指令（5.3）将其分配决策传递给SGX实现。该操作系统还可以将EPC页面驱逐到不可信的DRAM中，然后使用专用的CPU指令将它们加载回来。SGX使用加密保护来确保被驱逐的EPC页面的机密性、完整性和新鲜度。

SGX enclave的内存布局、特殊指令、将代码和数据加载进enclave、操作系统分配页面给enclave、保证enclave页面的机密性完整性新鲜性的内存加密、远程认证、模式切换、地址转换、enclave内部中断的处理AEX

1.2 大纲和问题发现

关于英特尔SGX的安全属性的推理需要大量的背景信息，这些信息目前分散在许多来源中。因此，这项工作的很大一部分是致力于总结这一先决条件的知识。

第2节总结了英特尔架构的相关子集和最近的英特尔处理器的微架构特性。第3节概述了可信硬件系统周围的安全景观，包括加密工具和相关的攻击类。最后，第4节简要描述了组成创建SGX的上下文的可信硬件系统。

在回顾了背景信息之后，第5节提供了SGX的编程模型（有时是费力的）详细描述，主要基于英特尔的软件开发手册。

第6节分析了其他公共信息来源，如英特尔与SGX相关的专利，以填写SGX描述中缺失的一些细节。本节最后详细回顾了SGX的安全属性，并利用了本文其余部分中介绍的信息。这篇综述概述了SGX在安全保障方面的一些令人不安的差距，以及一些如果没有英特尔的额外信息就无法得出结论的领域。

话虽如此，在我们的安全分析中，也许最令人不安的发现是，英特尔在SGX中添加了一项启动（launch）控制功能，该功能迫使每台计算机的所有者获得第三方（目前是英特尔）的批准，以获得所有者希望在计算机上使用的任何飞地。5.9解释说，该发布控制功能的唯一公开记录的预期用途是许可机制，该机制要求软件开发人员与英特尔签订（但未指明）商业协议，以便能够编写利用SGX保护的软件。所有的官方文档都谨慎地回避了这个问题，并有少量的提示导致英特尔在SGX上获得专利。只有这些专利披露了许可计划的存在。

许可问题现在可能没有太大的关联，因为我们的安全分析显示，SGX保证中的限制意味着具有安全意识的软件开发人员不能依靠SGX来进行安全的远程计算。与此同时，如果SGX能够开发出更好的安全属性，上述许可方案将成为一个主要问题，因为英特尔在桌面和服务器cpu上的市场份额近乎垄断。具体来说，许可限制有效地赋予了英特尔在依赖云计算的行业中选择赢家和输家的能力。

第二章 Intel体系架构背景知识

本节试图总结英特尔最流行的计算机处理器背后的一般架构原则，以及推理在这些处理器上运行的系统的安全特性所需的特性。除非另有说明，此处的信息汇总自英特尔的软件开发手册（SDM）[101]。

分析一个软件系统的安全性需要了解软件执行环境中所有部分之间的交互，所以这部分很长。我们在这里确实避免引入任何安全概念，所以熟悉x86的复杂问题的读者可以安全地跳过本节，并在必要时参考它。

我们使用术语英特尔处理器或英特尔CPU来指代英特尔酷睿系列的服务器和桌面版本。为了空间和理智，我们忽略了英特尔的其他处理器，比如Atomcpu，或者失败的安腾line。因此，术语英特尔计算机和英特尔系统指的是围绕英特尔的核心处理器构建的计算机系统。

在本文中，术语Intel体系结构指的是英特尔的SDM中描述的x86体系结构。x86架构过于复杂，主要是因为需要支持直接在CPU上执行1990年的遗留软件，而不需要软件解释的开销。我们只涵盖现代64位软件可见的体系结构部分。

本节所介绍的64位版本的x86体系结构，实际上是由高级微设备公司（AMD）发明的，也被称为AMD64、x86 64和x64。术语“英特尔架构”突出了我们对该架构在英特尔芯片上的实现的兴趣，以及我们想要了解英特尔SGX设计师的心态的愿望。

2.1 Overview

一个计算机的主要资源是内存和处理器。在Intel计算机中，动态随机存取存储器（DRAM）芯片提供了内存，一个或多个CPU芯片公开逻辑处理器。这些资源由系统软件管理，在Intel中运行两种典型的系统软件，即操作系统和hypervisors（管理程序）。

hypervisor又称虚拟机监视器（英语：virtual machine monitor，缩写为 VMM），是用来建立与执行虚拟机器的软件、固件或硬件。
被Hypervisor用来执行一个或多个虚拟机器的电脑称为主体机器（host machine），这些虚拟机器则称为客体机器（guest machine）。hypervisor提供虚拟的作业平台来执行客体操作系统（guest operating systems），负责管理其他客体操作系统的执行阶段；这些客体操作系统，共同分享虚拟化后的硬件资源。
hypervisor是所有虚拟技术的核心。
x86的管理程序主要分为下边三种架构：1.裸机型，直接安装在硬件资源上，管理硬件资源，操作系统运行并安装在hypervisor之上，2.宿主型，经过操作系统管理硬件资源。最常见的是这两种。

Intel机构被设计来支持运行多个应用程序软件实例，称为进程。操作系统分配计算机的资源来运行进程。服务器计算机，尤其是在云环境中，可能会同时运行多个操作系统实例。这是通过让一个系统管理程序hypervisor将计算机的资源分区在计算机上运行的操作系统实例之间来实现的。

系统软件使用虚拟化技术将其管理的每一个软件（进程或操作系统）与计算机上运行的其他软件隔离开来。这种隔离是将软件复杂性保持在可管理级别的关键工具，因为它允许应用程序和操作系统开发人员专注于他们的软件，而忽略与可能在计算机上运行的其他软件的交互。

虚拟化的一个关键组件是地址转换，它被用来给软件一种它拥有计算机上所有内存的印象。地址转换提供了隔离，防止一个错误或恶意软件通过修改其内存内容直接损坏其他软件。

虚拟化的另一个关键组件是由CPU强制执行的软件特权级别。硬件特权分离确保了一个漏洞或恶意软件不会通过干扰管理它的系统软件而间接损害其他软件。

进程通过创建执行线程来表达它们的计算能力需求，这些执行线程由操作系统分配给计算机的逻辑处理器。线程包含一个执行上下文，这是执行计算所需的信息。例如，一个执行上下文存储了将由处理器执行的下一条指令的地址。

操作系统给每个进程一种错觉，即它有无限数量的逻辑处理器可供处理，并在每个进程创建的线程之间重用可用的逻辑处理器。现代操作系统实现了抢占式的多线程，其中逻辑处理器每隔几毫秒就会在系统上的所有线程之间旋转一次。更改分配给逻辑处理器的线程是通过一个执行上下文切换来完成的。

虚拟机管理程序向每个操作系统公开固定数量的虚拟处理器（vcpu），并使用上下文切换，在呈现给客户操作系统的vcpu之间对逻辑cpu进行多路复用。

逻辑处理器中的执行核心可以以比DRAM提供快得多的速度执行指令和消耗数据。现代计算机架构中的许多复杂性都源于对弥补这种速度差距的需要。最近的Intelcpu依赖于超线程（2.9.4）、无序执行（2.10）和缓存（2.11），所有这些都有安全影响。

英特尔处理器包含许多级别的中间内存，比DRAM快得多，但也要小几个数量级，最快的中间内存是逻辑处理器的寄存器文件（2.2、2.4、2.6）。其他的中间内存被称为缓存（2.11）。

英特尔计算机有多个逻辑处理器。因此，它们在CPU芯片上也有多个缓存。在多套接字系统上，缓存分布在多个CPU芯片上。因此，Intel系统使用缓存一致性机制（2.11.3），以确保所有缓存具有相同的DRAM视图。由于缓存的一致性，程序员可以构建不知道缓存的软件，并且在分布式缓存的存在下仍然能正常运行。但是，缓存的一致性并不包括地址转换（2.11.5）所使用的专用缓存，系统软件必须采取特殊措施来保持这些缓存的一致性。

cpu通过I/O设备（也称为外设）与外部世界进行通信，如网络接口卡和显示适配器（2.9）。从概念上讲，CPU通过一个连接所有这些组件的系统总线与DRAM芯片和I/O设备进行通信。

为Intel架构编写的软件通过I/O地址空间（2.4）和内存地址空间与I/O设备进行通信，内存地址空间主要用于访问DRAM。系统软件必须配置CPU的缓存（2.11.4），以识别I/O设备使用的内存地址范围。设备可以通过调度中断（2.12）通知CPU事件的发生，导致逻辑处理器停止执行其当前线程，并在系统软件（2.8.2）中调用特殊处理程序。

英特尔系统有一个高度复杂的计算机初始化序列（2.13），因为需要支持大量的外设，以及针对不同版本的体系结构的许多操作系统。初始化序列对任何试图保护英特尔计算机的尝试都是一个挑战，并促进了许多安全妥协（2.3）。

英特尔的工程师使用处理器的微码设施（2.14）来实现英特尔架构中更复杂的方面，这大大有助于管理硬件的复杂性。这个微代码对软件开发人员来说是完全看不见的，而且它的设计大多是没有文档记录的。然而，为了评估任何架构更改建议的可行性，必须能够区分可以在微码中实现的更改和只能通过修改硬件实现的更改。

---

总结： 计算机中最主要的资源是CPU和内存，由操作系统和虚拟管理系统等系统软件来管理这些资源。其中支持多个应用程序软件同时运行，称为进程，进程又有许多线程组成，由虚拟技术来隔离这些软件（虚拟技术通过地址转换和软件特权级别实现），使得软件出现一种计算机资源独享的感觉。
为了降低CPU与内存之间的速度差，有速度最快的是寄存器，其次是缓存cache，要保持缓存一致性，使得所有缓存具有相同的DRAM视图。
CPU通过外部设备（I/O）与外部世界进行通信。

2.2 计算模型

本节为实现Intel架构的计算机提供了一个高度简化的模型，如图4所示。这个简化的模型旨在帮助读者的直觉处理论文其余部分使用的基本概念。下面的部分逐步将简化的模型细化为对Intel体系结构的详细描述。

一个计算机的核心的处理器和内存，他们通过一个系统总线连接，计算机也有I/O设备，比如键盘，外设也是通过系统总线与处理器连接。

内存是一个存储单元的数组，从0开始使用自然数进行寻址，并实现了图5中所示的抽象。它的显著特征是，在一个地址上读取一个内存单元的结果必须等于写入到该内存单元的最新值。

该处理器具有一个内部内存，称为寄存器文件。寄存器文件是由静态随机存取存储器单元组成，通常称为寄存器，他们比DRAM单元快很多，但是也贵挺多。
指令对其输入执行简单的计算，并将结果存储在输出位置。处理器的寄存器组成了一个执行上下文，它提供输入并存储大多数指令的输出。例如，ADD RDX、RAX、RBX执行一个整数加法，其中输入是寄存器RAX和RBX，结果存储在输出寄存器RDX中。
图6中提到的寄存器是指令指针（RIP），它存储了处理器要执行的下一条指令的内存地址，以及堆栈指针（RSP），它存储了处理器的过程性编程支持所使用的调用堆栈中的最顶层元素的内存地址。
当一条指令导致故障时，处理器将停止其正常的执行流程，并执行2.8.2中记录的故障处理程序进程。简而言之，处理器首先根据故障的性质查找将处理故障的代码的地址，并设置执行环境，以准备执行故障处理程序。
处理器通过系统总线相互连接并连接到内存上，系统总线是一个实现图7中抽象的广播网络。

在每个时钟周期中，连接到系统总线的设备最多可以发送一条消息，由连接到系统总线的所有其他设备接收。连接到总线上的每个设备将解码总线上发送的所有消息的操作代码和地址，并忽略不需要其参与的消息。
例如，当处理器希望读取存储位置时，它发送具有操作代码read请求和与期望存储位置对应的总线地址的消息。内存会在总线上看到消息并执行READ操作。在稍后的时间里，内存通过发送具有操作代码READ-响应、与请求相同的地址和数据值设置为READ操作的结果的消息来响应。
计算机通过I/O设备与外界进行通信，如键盘、显示器和网卡，这些设备都连接到系统总线上。设备大多响应处理器发出的请求。然而，设备也能够发出中断请求，通知处理器的外部事件，例如用户按下键盘上的一个键。
中断触发将在2.12中进行讨论。在现代系统中，设备通过对特殊的总线地址发出写操作来发送中断请求。中断被认为是硬件异常，就像故障一样，并以类似的方式处理。

总结： 这一小节介绍了计算机的各个结构，通过系统总线连接和通信，各个寄存器的作用，故障处理，中断等。

2.3 软件权限级别

在基础设施即服务（IaaS）云环境中，如Amazon EC2，商品cpu在四个不同的特权级别上运行软件，如下图所示：

每个特权级别都比下面的特权级别更强大，因此一个软件可以自由读取和修改运行在较低特权级别的代码和数据。因此，一个软件模块可以被任何运行在更高特权级别的软件所破坏。因此，一个软件模块隐式地信任运行在更多特权级别上的所有软件，并且系统的安全分析必须考虑到所有特权级别上的软件。
系统管理模式（SMM）是为主板制造商实现风扇控制和深度睡眠等功能，和/或模拟缺失的硬件。
因此，计算机固件中的引导软件（§2.13）负责将DRAM的连续子集设置为系统管理RAM（SMRAM），并将需要在SMM模式下运行的所有代码加载到SMRAM中。SMRAM享有特殊的硬件保护，以防止享有较低特权的软件访问SMM代码。
IaaS云提供商允许其客户在虚拟化环境中运行其选择的操作系统。硬件虚拟化[181]，被Intel称为虚拟机扩展（VMX），增加了对系统管理程序的支持，在Intel文档中也称为虚拟机监视器（VMM）。虚拟机监控程序以比操作系统更高的特权级别（VMX根模式）运行， 并负责在共享同一物理机器的多个操作系统之间分配硬件资源。该管理程序使用CPU的硬件虚拟化特性，使每个操作系统都相信它是在自己的计算机上运行的，这被称为虚拟机（VM）。管理程序代码通常在VMX根模式下以环0运行。
系统研究文献建议将操作系统分解成一个小内核，这个小内核运行在高特权级别，称为内核模式或监督模式，在Intel体系结构中，称为环0。内核将计算机的资源分配给其他系统组件，如以较低的特权级别运行的设备驱动程序和服务。然而，由于性能原因，主流操作系统有大量的代码在环0处运行。它们的单片内核包括设备驱动程序、文件系统代码、网络堆栈和视频渲染功能。
应用程序代码，如Web服务器或游戏客户端，运行在最低的特权级别，称为用户模式（在Intel架构中的环3）。在IaaS云环境中，客户提供的虚拟机映像在VMX非根模式下运行，因此内核在VMX非根环0中运行，而应用程序代码在VMX非根环3中运行。

总结： 介绍了计算机的软件特权级别，高一级别的软件可以访问低级别的资源。

2.4 地址空间

为英特尔体系结构编写的软件使用四个不同的物理地址空间访问计算机的资源，如图9所示。地址空间在目的和内容上部分重叠，这可能导致混淆。本节提供了由Intel架构定义的物理地址空间的高级概述，重点介绍了它们的目的和用于管理它们的方法。

四个物理地址空间：寄存器和MSR是CPU内部的，内存地址空间和I/O地址空间被用来在DRAM和其他设备之间的通信通过系统总线。

寄存器空间由用于访问CPU的寄存器文件的名称组成，这是唯一在CPU的时钟频率下运行的内存，可以使用而没有任何延迟惩罚。寄存器空间由CPU的体系结构定义，并记录在SDM中。（寄存器空间是由寄存器文件组成）

一些寄存器，如控制寄存器（CRs），在配置CPU的操作中发挥着特定的作用。例如，CR3在地址翻译中起着核心作用（2.5）。这些寄存器只能通过系统软件进行访问。其余的寄存器组成了一个应用程序的执行上下文（2.6），这本质上是一个高速的抓取空间。这些寄存器可以在所有特权级别上访问，它们的分配由软件的编译器管理。许多CPU指令只对寄存器中的数据进行操作，并且只将其结果放在寄存器中。

内存空间，通常称为地址空间，或物理地址空间，由2^36个（64 GB）- 2 ^40个（1 TB）地址组成。内存空间主要用于访问DRAM，但它也用于与内存映射设备通信，这些设备从系统总线上读取内存请求并为CPU写响应。一些CPU指令可以从内存空间读取它们的输入，或者使用内存空间存储结果。

输入/输出（I/O）空间由2 ^16个I/O地址组成，通常称为端口。I/O端口专门用于与设备进行通信。CPU提供了从读取和写入I/O空间的特定指令。I/O端口按照正式的或事实上的标准分配给设备。例如，端口0xCF8和0xCFC总是用于访问PCIexpress（2.9.1）配置空间。

特定模型的寄存器（MSR）空间由2 ^32个MSR组成，用于配置CPU的操作。MSR空间最初打算用于使用特定于CPU模型的固件，但一些MSR已经被提升到架构中的MSR状态，使它们的语义成为Intel架构的一部分。例如，体系结构MSR 0x10拥有一个高分辨率、单调递增的时间戳计数器。
总结： 这一小节介绍了CPU和系统总线里的地址空间，计算机通过使用这四种地址空间来访问计算机上的资源。

2.5 地址转换

系统软件依赖于CPU的地址转换机制来实现在较低特权的软件部分（应用程序或操作系统）之间的隔离。几乎所有安全体系结构设计都为地址转换带来变化。

我们总结Intel体系结构的地址转换特性在建立系统的安全属性时最相关，并向读者参考[108]以了解地址翻译概念及其其他用途的更一般的介绍。

2.5.1 地址转换概念

从系统的角度来看，地址转换是由程序的内存加载和存储指令使用的虚拟地址和引用物理地址空间（2.4）的物理地址之间的一个间接层（如图10所示）。虚拟地址和物理地址之间的映射由由系统软件管理的页表来定义。

操作系统使用地址转换来实现虚拟内存抽象，如图11所示。虚拟内存抽象公开了与2.2中的内存抽象相同的接口，但是每个进程都使用一个单独的虚拟地址空间，该空间只引用分配给该进程的内存。从应用程序开发人员的角度来看，虚拟内存可以通过假装每个进程都运行在单独的计算机上，并有自己的DRAM来进行建模。

操作系统使用地址转换在多个应用程序进程之间多路复用DRAM，将进程彼此隔离，并防止应用程序代码直接访问被内存映射的设备。后两种保护措施可以防止应用程序的bug影响其他应用程序或操作系统内核本身。管理程序还使用地址转换，在并发运行的操作系统之间划分DRAM，并虚拟化与内存映射的设备。
64位操作系统所使用的地址转换模式，被Intel的文档称为IA-32e，它将48位虚拟地址映射到最多52位的物理地址。转换过程，如图12所示，是由CPU中的专用硬件执行的，这被称为地址转换单元或内存管理单元（MMU）。

除了隔离应用程序进程外，操作系统还使用地址转换特性来运行其集体内存需求超过计算机中安装的DRAM数量的应用程序。该操作系统会将很少使用的内存页面从DRAM转移到较大（但较慢）的存储器中，如硬盘驱动器（HDD）或固态驱动器（SSD）。由于历史原因，这个较慢的内存被称为磁盘。

2.5.2 地址转换和虚拟化

2.5.3 页表属性

2.6 执行上下文

2.7 段寄存器

2.8 特权级别转换

2.9 计算机map

2.10 Out-of-Order and Speculative Execution

2.11 缓存cache

2.12 中断

2.13 平台初始化（Booting）

2.14 CPU微码

第三章 安全知识背景

3.1 密码学原语

3.1.1 密码学秘钥

3.1.2 机密性

3.1.3 完整性

许多提供完整性保证的密码学系统都是建立在安全的哈希函数之上的。这些哈希函数对无限数量的输入数据进行操作并产生一个小的固定大小的输出。安全哈希函数有一些保证，例如抗原象攻击，它表明对手不能产生与给定哈希输出相对应的输入数据。
在撰写本文时，最流行的安全哈希函数是安全哈希算法（SHA）[48]。但是，由于SHA-1 [173]中的安全问题，建议新软件至少使用256位SHA-2 [21]进行安全散列。
SHA哈希函数是一个大型块哈希函数家族的成员，这些函数消耗它们在固定大小的消息块中的输入，并使用固定大小的内部状态。我们使用了一个块散列函数，如图41所示。首先会调用一个INITIALIZE算法来将内部状态设置为其初始值。对输入中的每个消息块都执行一个EXTEND算法。在消耗了整个输入之后，一个FINALIZE的算法从内部状态产生哈希输出。

在对称密钥设置中，使用消息身份验证码（MAC）密码系统获得了完整性保证，如图42所示。发送方使用一种MAC算法，该算法读取一个对称的密钥和一个可变长度的消息，并产生一个固定长度的、较短的MAC标记。接收方将原始消息、对称密钥和MAC标记提供给MAC验证算法，用以检查消息的真实性。

MAC密码系统的密钥属性是一个对手不能产生一个没有密钥来验证消息的MAC标记。许多MAC加密系统没有一个单独的MAC验证算法。相反，接收方通过运行与发送方相同的算法来计算MAC标签，并将输出与从网络接收的MAC标签进行比较。
这是哈希消息身份验证码（HMAC）[124]通用构造的情况，其操作如图43所示。HMAC可以使用任何安全的哈希函数，如SHA，来构建一个MAC加密系统。

提供完整性保证的非对称密钥原语被称为签名。消息发送方为签名算法提供其私钥，并与消息一起发送输出签名，如图44所示。消息接收方将发送方的公钥和签名输入签名验证算法，如果消息匹配签名，该算法返回TRUE。

签名算法只能对较小的消息进行操作，而且计算代价高昂。因此，在实践中，要传输的消息首先通过一个密码学上的强哈希函数运行，并将该哈希作为签名算法的输入提供。
在撰写本文时，保证共享秘密设置中完整性的最流行的选择是HMAC-SHA，这是一个使用SHA进行散列的HMAC函数。
身份验证加密结合了分组密码和操作模式，提供了一致性和完整性的保证，通常是HMAC的一个有吸引力的替代方案。最流行的身份验证加密操作模式是Galois/计数器操作模式（GCM）[137]，当它与AES结合形成AES-GCM时，已经获得了NIST的推荐[47]。
最流行的签名方案将RSA加密算法与PKCS #1中指定的填充方案结合起来，如图45所示。最近，椭圆曲线密码学（ECC）[121]由于其较小的密钥大小而大受欢迎。例如，一个384位的ECC密钥被认为与一个3072位的RSA密钥[20,143]一样安全。美国国家安全局要求数字签名标准（DSS）[142]，它规定了基于RSA和ECC的方案。

3.1.4 新鲜性

3.3 Software Attestation Overview

应用可信处理器的系统的安全性依赖于软件认证。软件运行在由可信硬件构建的隔离容器内，可以要求硬件签名一小部分认证数据，从而生成一个认证签名。除了认证数据外，签名消息还包括唯一标识容器内软件的度量。因此，认证签名可以用来让验证者相信验证数据是由一个特定的软件产生的，该软件托管在一个容器中，被可信的硬件与外部干扰隔离。
本节中讨论的每个硬件平台都使用了一个略有不同的软件认证方案。

3.3.1 认证秘钥协商

软件认证可以与密钥协商协议（3.2.2）结合起来，因为软件认证提供了密钥协商协议所需的认证。由此产生的协议可以向验证者保证，它已经与特定软件建立了共享秘密，该软件托管在由可信硬件创建的隔离容器中（ “The resulting protocol” 可以确保验证者与托管在由可信硬件创建的隔离容器内的特定软件建立了共享密钥。）。这里以Diffie-Hellman秘钥交换协议作为例子概述扩展协议。
验证者开始执行秘钥交换协议，并发送第一个消息$g^A$给安全容器中的软件。在安全容器中的软件生成第二个秘钥交换消息$g^B$，并要求可信硬件认证这两个秘钥交换消息的哈希值$h(g^A||g^B)$。验证者接收到第二个秘钥交换消息和认证签名，并通过检查图53中所示的可信认证链上的所有签名，对安全容器内的软件进行身份验证。

软件认证的可信链。信任的根是制造商密钥，它为安全处理器的认证密钥生成背书证书。处理器使用认证密钥来产生认证签名，该签名包含容器的加密哈希和由容器内的软件生成的消息。

软件认证中使用的信任链植根于硬件制造商拥有的签名密钥，该密钥必须受到验证者的信任（换句话说，软件认证的可信根是硬件制造商拥有的签名秘钥）。制造商充当证书颁发机构（CA，3.2.1），并为其生成的每个安全处理器提供一个唯一的认证密钥，该密钥用于生成认证签名。制造商还为每个安全处理器的认证密钥颁发背书证书。该证书表明该密钥将用于软件认证。认证策略通常规定，至少，认证密钥的私有部分可以存储在防篡改的硬件中，并且仅用于产生认证签名。
安全处理器通过存储加载在容器中的代码和数据的加密哈希来标识每个隔离的容器。当处理器被要求对一段认证数据进行签名时，它会使用与该容器相关联的加密散列作为认证签名中的度量。在验证者使用背书证书验证处理器的认证秘钥后，验证者确保签名是合法的，并且签名中的度量属于它期望与之进行通信的软件。在检查了认证链中的所有链接后，验证者已经对密钥交换中的另一方进行了身份验证，并保证它现在与它期望的软件共享一个秘密，该软件在它信任的硬件上的隔离容器中运行。

3.3.2 软件度量的作用

标识安全容器内的软件的度量总是使用安全哈希算法进行计算。可信的硬件设计在其安全的哈希函数选择和提供给哈希函数的数据方面有所不同。然而，所有的设计都有这样的原则，即构建安全容器的每个步骤都为其度量哈希提供数据。
软件认证背后的理念是，计算机的所有者可以在一个安全的容器中加载任何她希望加载的软件。然而，计算机所有者被认为有参与分布式系统的动机，她构建的安全容器通过软件认证进行认证。在不需要进行软件认证的情况下，计算机所有者可以在没有限制的情况下构建任何容器，这将使人们无法对容器内软件的安全特性进行推理。
根据上述论证，基于软件认证的可信硬件设计必须假设每个容器都涉及到软件认证，并且远程方将拒绝与报告的度量与分布式系统作者设置的期望值不匹配的容器进行交互。
例如，云基础设施提供商应该能够使用可信硬件提供的安全容器来在她的计算机上运行她希望运行的任何软件。然而，该供应商通过将其基础设施出租给客户来赚钱。如果精通安全的客户只愿意租容器由可信的硬件，并使用软件认证来验证他们使用的容器，云提供商将有一个强大的金融激励根据客户的规范构建客户的容器，这样容器通过软件认证。
容器的度量是使用安全哈希算法计算的，因此构建匹配预期度量的容器的唯一方法是遵循分布式系统作者指定的精确步骤序列。安全哈希函数的加密属性保证，如果计算机的所有者以任何方式偏离规定的步骤序列，创建容器的测量将不匹配分布式系统的作者预期的值，所以容器将拒绝软件认证过程。
因此，声明一个可信的硬件设计的度量方案保证了一个属性在一个安全的容器中具有一定的值是有意义的。这个短语的确切含义是，属性的值决定了用于计算容器度量的数据，因此预期度量散列有效地指定了属性的期望值。分布式系统中正确使用软件认证的所有容器都将具有给定属性所需的值。
例如，为云基础设施设计的可信硬件所使用的度量方案应该保证容器的内存被使用客户的内容进行初始化，通常被称为镜像。

第五章 SGX Programming Medol

SGX的核心概念就是enclave，是一个受保护的环境，其包含对安全敏感计算有关的代码和数据。
支持SGX的处理器提供可信计算，通过将不可信的软件隔离在enclave外来隔离每个enclave的环境，并且通过实现一个软件验证方案（software attestation）允许一个远程party来认证其软件运行在enclave中。SGX的隔离机制旨在保护在enclave里执行的计算的机密性和完整性，免受来自在同一计算机上执行的恶意软件的攻击，以及有限的物理攻击。
这一章总结了SGX的概念。本章的信息来源于Intel’s Software Developer Manual。

总结： SGX的enclave，提供隔离环境和认证功能，隔离包括enclave之间的隔离和enclave和不可信软件的隔离，认证包括本地enclave之间的认证和远程认证。为在enclave运行的数据和代码提供机密性和完整性。

5.1 SGX物理内存组织

enclave的代码和数据存储在Processor Reserved Memory（PRM，处理器预留内存）中，该内存是DRAM的子集，并且该内存不能由其他软件（包括系统软件和SMM code）直接访问。CPU的集成内存控制器（MMU？）也拒绝针对PRM的MDA传输，从而保护该内存不被其他外设访问。

总结：enclave的代码和数据放在内存DRAM里的一块专有内存PRM中，其中该内存不被其他特权软件访问，也不被DMA访问。（DMA是不经过CPU就直接能从内存存取数据的数据交换模式）

PRM是一个连续的内存范围，其bounds由base和一个掩码寄存器进行设置，其语义和 a variable memory type range（2.11.4中有讲）相同。因此，PRM的大小必须是2的整数次幂，并且它的起始地址必须与2的相同次幂对齐。由于这些限制，检查一个地址是否属于PRM是很简单就由硬件完成，使用2.11.4概述的电路。

这里讲的是PRM这块内存地址的限制，使得该内存地址更容易的与其他普通内存区分，更好的实现隔离。

Intel的软件开发手册里没有描述PRM和PRM范围寄存器（PRMRR）。这些概念是在SGX的手册和SGX的论文中描述的。因此，PRM是一个微架构细节。我们对SGX的安全分析依赖于围绕PRM的实现细节。

5.1.1 The Enclave Page Cache（EPC）

enclaves的内容和其有关的数据结构都存储在EPC中，EPC是PRM的子集。

SGX的设计支持在一个系统上同时有多个enclaves，这在多进程环境中时必要的。这是通过将EPC分成4KB的页面，可以分配给不同的Enclaves。EPC使用与体系结构的地址转换特性相同的页面大小。这并不是是一个巧合，因为未来的部分将揭示SGX实现与地址转换实现是紧密结合的。
EPC由管理计算机其余物理内存的同一系统软件管理。该系统软件可以是hypervisor（系统管理程序），或者是OS kernel，它使用SGX指令将未使用的页面分配给enclaves，并释放以前分配的EPC页面。该系统软件预计将enclaves的创建和管理服务暴露给应用程序软件。
Non-enclave软件不能直接访问EPC，因为它包含在PRM中，这种限制在SGX的enclave隔离保证中起着关键作用，但当系统软件需要将初始化代码和数据加载到一个新创建的enclave时，就会造成障碍。SGX设计通过将EPC页面分配给enclave的指令的同时也初始化这个页面来解决这个问题。大多数EPC页面都是通过从Non-PRM内存页面中复制数据来初始化的。

总结：EPC是PRM处理器预留内存的一部分，而PRM又是DRAM的一部分，所以EPC也可以说是DRAM的一部分。PRM是一块受保护的内存，除了EPC还有其他数据。
EPC由4KB大小的页面组成，这些页面可以分配给不同的enclaves。一个系统上可以有多个enclaves并存，支持多进程操作。
EPC由不可信的操作系统管理，使用SGX特定指令来分配和销毁
分配页面的同时也进行了数据初始化，将数据复制到EPC页中。

5.1.2 The Enclave Page Cache Map（EPCM）

SGX的设计希望系统软件将EPC页面分配给enclaves，但是，由于系统软件是不可信的，SGX处理器将会检查系统软件的分配决策的正确性，并拒绝执行任何会危及SGX的安全保证的操作。例如，如果系统软件试图将相同的EPC页面分配给两个Enclaves，则用于执行该分配的SGX指令将会失败。
为了执行其安全检查，SGX会在EPCM中记录关于每个EPC页面的系统软件分配决策的一些信息。EPCM是一个数组，每个EPC页面有一个条目，所以计算一个页面的EPCM条目的地址只需要逐位移位操作和加操作。
EPCM的内容只用于SGX的安全检查。在正常的运行下，EPCM不会产生任何软件可见的行为，Enclave所有者和系统软件开发人员大多可以忽略它。因此，开发手册上只在非常高的级别上描述EPCM，列出其中包含的信息，并指出EPCM是“可信的内存”，开发手册没有公开EPCM所使用的存储介质或内存布局。
EPCM使用下表中的信息来跟踪每个EPC页面的所有权。我们将EPCM的完整讨论推迟到后面的部分，因为他的内容与SGX的所有特性紧密相关，这将在接下来的几个部分中进行描述。

分配一个EPC页面的SGX指令将相应的EPCM条目的VALID位设置为1，并拒绝对已经设置了VALID位的EPC页面进行操作。
用于分配EPC页面的指令还确定了页面的预期用途，该用途记录在相应EPCM条目的页面类型（PT）字段中。存储一个enclave的代码和数据的页面被认为具有一个常规类型（regular type，在手册中的PT_REG）。专门用于存储SGX的支持数据结构的页面被标记为特殊类型，例如，PT_SECS类型标识了包含SGX enclave控制结构的页面。
最后，一个页面的EPCM条目还标识了拥有EPC页面的enclave。这些信息被强制执行SGX的隔离保证的机制所使用，以防止一个enclave访问另一个enclave的隐私信息。由于EPCM为每个EPC页面标识一个拥有的enclave，因此enclaves不可能使用EPC页面通过共享内存进行通信。幸运的是，enclaves可以共享不可信的Non-EPC内存，这将在5.2.3中讨论。

因为EPC页面是由不可信的系统软件分配的，所以SGX设计了一种安全检查机制EPCM来检查系统软件的分配是否正确，EPCM可以理解成一个多维数组，每个数组元组对应一个EPC页面，记录该EPC页面是否被分配、页面类型、该页面分配给了哪个enclave。

5.1.3 The SGX Enclave Control Structure（SECS）

SGX将每个enclave的元数据存储在与每个enclave关联的SGX enclave control structure（SECS）中。每个SECS都存储在一个专用的EPC页面中，页面类型为PT_SECS。这些页面不被映射到任何enclaves的地址空间，而是由CPU的SGX实现专门使用的。
一个enclave的身份几乎是它的SECS的同义词。激活一个enclave的第一步就是分配一个EPC页面作为该enclave的SECS，而销毁一个enclave的最后一步是释放所持有的SECS的页面。EPCM的条目字段标识了这个enclave拥有这个EPC页面，该字段指向这个enclave的SECS。系统软件调用SGX指令时，使用一个enclave的SECS虚拟地址来识别该enclave。
所有的SGX指令都以虚拟地址作为其输入。鉴于SGX指令使用SECS地址来识别enclaves，系统软件必须在其页表中创建指向其管理的enclave的ESCS的条目。但是，系统软件无法访问任何的SECS页面，因为这些页面存储在PRM中。SECS页面不被映射到其enclave的虚拟地址空间中，并且启用了SGX的处理器显示地阻止enclave代码访问SECS页面。
SGX实现可以在SECS中存储敏感信息，并且能够假设没有潜在的恶意软件会访问这些信息。例如，开发文档中声明每个enclave的度量都存储在SECS中。如果软件能够修改一个enclave的度量值，那么SGX软件认证方案将不会提供任何的安全保证。
SECS与SGX的许多特性紧密结合，因此，随着SGX的介绍，将逐步介绍组成SECS的信息。

标识enclave的身份信息等元数据存放在SECS中，该SECS是一个专有EPC页面，与enclave的数据和代码的页面类型不同。不映射到enclave的虚拟地址空间，并且不允许enclave代码访问。
软件系统要分配EPC页面时，无法访问任何的SECS的页面，需要在页表上创建指向SECS的条目。（系统软件维护的这个页表需要了解）
明晰ECPM和ESCS的关系：EPCM中的条目中有一个字段，指向该enclave的ESCS。

EPCM对于系统软件是否可见？

5.2 An SGX Enclave的内存布局

SGX的设计目的是最小化影响，即需要转换应用代码来利用enclaves。历史证明，这是一个明智的决定，因为Intel架构持续占据主导地位的一个重要因素是他保持向后兼容的能力。为此，SGX enclaves被设计成在概念上类似于软件模块化构造，动态加载库，它们被打包为Unix上的.so文件，Windows上的.dll文件。
为了简单起见，我们描述了enclaves和non-enclaves软件之间的交互，假设每个enclave只由一个应用程序进程使用，我们称之为enclave的主进程。然而，注意到，SGX设计并没有明确禁止多个应用程序进程共享一个enclave。

5.2.1 The Enclave Linear Address Range（ELRANGE）

每个enclave在其虚拟地址空间中指定一个区域，称为enclave线性地址范围（ELRANGE），用于映射存储在该enclave的EPC页面中的代码和敏感数据。ELRANGE之外的虚拟地址空间被映射到通过与enclave的主进程相同虚拟地址来访问non-EPC内存，如下图所示。

这个图片：enclave的EPC页面使用enclave的虚拟地址空间中专有区域来访问。虚拟地址空间剩余的部分用来访问主程序的内存（non-EPC部分）。这个内存映射是使用系统软件管理的页表来建立的。

SGX设计保证enclave在ELRANGE里的内存访问服从虚拟内存抽象，但是ELRANGE之外的没有任何保证。因此，enclaves必须将所有的代码和隐私数据存储在ELRANGE内，并且必须将ELRANGE之外的内存看做是外部世界不可信的接口。

这里为了方便理解，放入2.5.1节内容：
从系统角度来看，地址转换是一个虚拟地址和物理地址之间的中间层。如下图所示。其中，虚拟地址用来加载一个程序的内存和存储指令的，物理地址指的是物理地址空间。

操作系统使用地址转换来实现虚拟内存抽象，如下图所示。虚拟内存抽象揭示了与2.2节中的内存抽象相同的接口，但是每个进程都使用一个单独的虚拟地址空间，该空间只引用分配给该进程的内存。从应用程序开发人员的角度来看，虚拟内存可以假装每个进程都运行在单独的计算机上，并有自己的DRAM来进行建模。

ELRANGE中的“线性”一次指的是64位Intel架构中的vestigial segmentation（详细看2.7节解释）特性所产生的的线性地址。在大多数情况下，“线性”可以被视为“虚拟” 的同义词。
ELRANGE可使用enclave的SESC中的base（BASEADDR字段）和size（SIZE）来指定。ELRANGE必须满足与variable内存类型范围（2.11.4）和PRM范围相同的约束条件，即大小必须为2的幂，并且base必须与大小对齐（这里不是很理解）。这些限制是这样的，以便SGX实现可以在硬件或者软件中容易地检查一个地址是否属于一个enclave的ELRANGE。
当一个enclave代表一个动态库时，自然会将ELRANGE设置为由loader为库保留的内存范围。从enclave代码访问non-enclave内存的能力使重用现有的库代码变得很容易，这些库代码希望与指向主进程中有代码管理的内存缓冲区的指针一起工作。
Non-enclave软件无法访问PRM内存，在PRM内部解析的内存访问会导致事务中止，该事务在架构级别上未定义，在当前的处理器上，中止写操作是被忽略的，中止读返回一个值，他们的位都被置为1。这在上面的应用场景中发挥作用，将enclave作为动态加载库加载到主程序进程中。该系统软件将这个enclave的代码和数据映射到EPC页面中。如果应用程序软件试图访问ELRANGE内的内存，他将会经历abort 事务语义。当前的语义不会导致应用程序崩溃（例如，页面故障），但也保证主应用程序不能篡改enclave或读取其隐私信息。

总结：这里主要讲的是enclave也是用到了内存抽象的概念，让程序运行者以为程序独占了内存空间。系统软件将虚拟内存和物理内存通过页表来映射，其中enclave映射的EPC内存由ELRANGE专有虚拟内存空间。ELRANGE的基地址和大小由ESCS结构确定。
思考：这里怎么联系系统软件与ESCS的关系？因为ESCS是在PRM里的，系统软件是访问不了的，那么系统软件管理的页表是如何映射到EPC的呢？

5.2.2 SGX enclave Attributes

Enclave的执行环境严重受到SECS中ATTRIBUTES字段的影响。本工作的其余部分将指出字段的子字段，如下表所示：

SECS结构中有一个字段是ATTRIBUTES，同时ATTRIBUTES字段中又有一些子字段。

从安全的角度看，最重要的属性是DEBUG标志。当设置此标志时，它允许为此enclave使用SGX的调试特性。这些调试特性包括能够读取和修改enclave的大部分内存。因此，DEBUG应该只在开发环境中设置，因为它会导致enclave失去所有的SGX安全保证。
SGX保证enclave的代码始终在将XCR0寄存器设置为extended features request mask（XFRM）所指示的值时运行。enclave的作者应该使用XFRM来指定用于生成enclave代码的编译器所启用的架构扩展集。明确指定XFRM允许Intel设计新的架构扩展，以改变现有的指令语义，如内存保护扩展（MPX），而不必担心在没有意识新特征的情况下开发的enclave代码的安全影响。
对于使用64位Intel架构的enclave，MODE64BIT标志被设置为真。从安全的角度来看，这个标志位甚至不应该存在，因为支持二级体系结构为SGX实现增加了不必要的复杂性。32位架构支持很可能是由于Intel提供广泛的向后兼容性的策略，这到目前为止已经获得了相当好的回报。
这个工作没有分析那些MODE64BIT标记被清除的enclave的SGX行为，然而，一个希望发现SGX漏洞的安全研究人员可能会研究这一领域。
最后，在创建enclave的SECS时，INIT标志总为FALSE。这个标志在enclave生命周期的某个点设置为TRUE，这将在5.3中总结。

总结：这些SECS的属性对enclave的调试，运行时的环境进行了设置。

5.2.3 Address Translation for SGX enclaves

在SGX下，系统软件和hypervisor仍然完全控制页表和EPTs（Extended Page Tables，扩展页表），并且每个enclave的代码使用与其主应用程序相同的地址转换进程和页表。这将最小化减少向现有的系统软件添加SGX支持所需的更改量。同时，通过不受信任的系统软件管理页表，将在3.7节中描述对SGX的地址转换攻击。正如未来章节将揭示的那样，SGX设计的大量复杂性可以归因于防止这些攻击的需要。
SGX的主动内存映射攻击防御机制围绕着确保每个EPC页面只能被映射到一个特定的虚拟地址。当分配EPC页面时，其预期的虚拟地址将记录在页面的EPCM条目ADDRESS字段中。
当地址转换结果是EPC页面的物理地址时，CPU确保提供给地址转换进程的虚拟地址与记录在页面的EPCM条目中的预期虚拟地址相匹配。
SGX还通过确保每个EPC页面的访问权限始终与enclave的所有者的意图匹配来防止一些被动内存映射攻击和错误注册攻击。对于每个EPC页面的访问权限，在分配页面时指定，并记录在页面的EPCM条目中的可读（R）、可写（W）和可执行（X）字段中，如下表所示：

当地址转换解析为EPC页面时，相应的EPCM条目字段将覆盖页表中指定的访问权限属性。例如，EPCM条目中的W字段覆盖可写（W）属性，而X字段覆盖禁止执行（XD）属性。

地址转换2.5节：CPU的地址转换机制。转换进程，是由CPU中的专有硬件执行的，被称为地址转换单元或内存管理单元（MMU）

因此，允许enclave的所有者必须知道enclave的同时知道内存布局信息，这样，加载enclave的系统软件将知道每个enclave页面的预期虚拟内存地址和访问权限。作为回报，SGX设计向enclave所有者保证，管理页表和EPT的系统软件将无法与所有者期望不一致的方式设置enclave的虚拟地址空间。
.so和.dll文件格式是SGX预期的enclave交付工具，他们已经规定了指定软件模块设计要使用的虚拟地址，以及每个模块内存区域的所需访问权限。
最后，启用SGX的CPU将确保ELRANGE内的虚拟内存映射到EPC页面。这可以防止系统软件执行地址转换攻击，即它将enclave的整个虚拟地址空间映射到PRM之外的DRAM页面，这些页面不会出发上述任何检查，并且可以被系统软件直接访问。

这节讲的是虚拟地址到物理地址的地址转换，enclave预期的虚拟地址放在EPCM中的ADDRESS字段中，以及enclave的访问权限都在EPCM中。系统软件分配页面时必须按照enclave所用者设置的访问权限设置页面。
地址转换需要依赖CPU的地址转换机制MMU。它来实现从虚拟地址到物理地址的映射，那么是不是能解决系统软件不接触EPC物理地址的问题？去了解一下地址转换，页表和地址转换机制的关系？

5.2.4 The Thread Control Structure（TCS）

SGX的设计完全采用了多核处理器。多个逻辑处理器可以通过不同的线程同时执行同一enclave的代码。
SGX实现对执行enclave代码的每个逻辑处理器使用线程控制结构（TCS）。因此，一个enclave的所有者必须提供至少与该enclave打算支持的最大并发线程数量相同的做多的TCS实例。
每个TCS都存储在一个专用的EPC页面中，其中EPCM条目类型为PT_TCS。手册中描述了TCS中的前几个字段。这些字段被认为属于结构的体系结构部分，因此保证在所有支持SGX的处理器上具有相同的语义。其余文档没有TCS的记录。
包含TCS的EPC页面的内容不能直接访问，即使是通过拥有TCS的enclave代码也不能直接访问。此限制类似于对包含SECS实例的EPC页面的访问限制。但是，TCS中的体系结构字段可以通过enclave的调试指令来读取。
TCS的体系结构字段展示了逻辑处理器在执行non-enclave代码和enclave代码之间转换时执行的上下文切换。
例如，OENTRY字段指定当TCS用于开始执行enclave代码时，在指令指针（RIP）中加载的值，因此enclave所有者对enclave的主应用程序可用的入口点有严格的控制。此外，OFSBASGX和OGSBASGX字段指定了加载在FS和GS段寄存器中的基本地址，这通常指向线程本地存储（TLS）。

总结：这节主要讲SGX允许并发执行，通过线程控制结构TCS满足。TCS是一个专有EPC页面，不被enclave的代码访问，和SECS结构类似。

5.2.5 The State Save Area（SSA）

当在enclave中执行代码时，当处理器遇到硬件异常，例如中断，它执行一个特权级别的转换并调用系统软件提供的硬件异常处理程序。但是，在执行异常处理程序之前，处理器需要一个安全区域来存储enclave代码的执行上下文，这样执行上下文中的信息就不会显示给不受信任的系统软件。
在SGX的设计中，在处理硬件异常时，用于存储enclave线程的执行上下文的区域称为State Save Area（SSA），如下图所示。每个TCS引用一个连续的SSA序列。The offset of the SSA array（OSSA）字段指定了该enclave的虚拟地址空间中的第一个SSA位置。The number of SSAs（NSSA）字段指定了可用的SSA的数量。

每个SSA从EPC页面的开头开始，并占用在enclave SECS的SSAFRAMESIZE字段中指定的EPC页面数。这些对齐和大小限制很可能通过减少需要处理的特殊情况的数量来简化SGX的实现。
一个飞地线程的执行上下文由通用寄存器（GPRs）和XSAVE指令（2.6）的结果组成。因此，执行上下文的大小取决于XSAVE所使用的requested-feature bitmap（RFBM）。一个飞地中的所有代码都使用相同的RFBM，该RFBM在XFRM飞地属性（5.2.2）中声明。为SSA指定的每个SSA保留的EPC页数必须足够大，以适合XFRM指定的feature bitmap的XSAVE输出。
SSAs存储在常规的EPC页面中，其EPCM页面类型为PT_REG。因此，SSA的内容可以被enclave软件访问，SSA的布局结构被完全的记录在开发手册中。这打开了主应用程序调用的飞地异常处理程序发生硬件异常的可能性，并对SSA中的信息进行操作。

总结：这节主要讲的是当执行enclave代码时，发生异常，则需调用系统软件执行异常处理程序。这里需要将enclave代码上下文安全的保存起来，SSA就是这个作用。

5.3 The life Cycle of an SGX enclave

enclave的生命周期与资源管理深深地交织在一起，特别是EPC页面的分配。因此，在不同生命周期状态之间转换的指令只能由系统软件来执行。系统软件预计将把下面描述的SGX指令作为enclave加载和销毁服务。下面的小节描述了一个enclave的生命周期中的主要步骤，如下图所示：

5.3.1 Creation

当系统软件发出ECREATE指令时，一个enclave就创建了，该指令将一个空闲的EPC页面转换为新enclave的SECS。
ECREATE使用系统软件拥有的non-EPC页面中的信息初始化这个新创建的SECS。此页面指定开发手册中定义的所有SECS字段的值，如BASEADDR和SIZE，使用保证在未来实现中保留的架构布局。

5.4 SGX线程的生命周期

在Enclave初始化和销毁的时间之内，Enclave的代码能被任意的应用程序进程执行，Enclave的EPC页映射到该应用程序的虚拟地址空间内。

当执行Enclave内的代码时，逻辑处理器在Enclave模式下，代码执行能访问属于当前执行Enclave的常规EPC页。当一个逻辑处理器在Enclave模式之外，他在处理器保留内存（PRM）范围内的任意内存访问将被限制，PRM包含EPC。

每个逻辑处理器执行Enclave代码使用一个线程控制结构（TCS）。当一个TCS被处理器使用时，它被置为busy，它不能被其他逻辑处理器使用。图65展示了主机进程执行Enclave代码使用的指令以及他们与目标TCS的交互。

5.6 SGX Enclave Measurement

SGX实现了一个遵循3.3中概述的一般原则的软件认证方案。就本节而言，最相关的原则是远程方根据其测量对飞地进行认证，旨在识别在飞地内执行的软件。远程方将受信任硬件报告的飞地度量与预期度量进行比较，并且仅在两个值匹配时才进行。
5.3解释了一个SGX飞地是使用ECREATE（5.3.1）、EADD（5.3.2）和EEXTEND指令构建的。通过EINIT（5.3.3）初始化飞地后，不能再使用上述指令。由于SGX测量方案遵循§3.3.2中概述的原则，因此SGX enclave的测量是通过在用于创建enclave并将初始代码和数据加载到其内存中的ECREATE、EADD和EEXTEND指令的输入上计算安全哈希（§3.1.3）来获得的。EINIT最终确定表示enclave测量值的散列。
除了飞地的内容之外，飞地作者还应该指定应该使用的指令序列，以创建一个飞地，其测量值将与远程方在软件认证过程中使用的预期值相匹配。.so和.dll动态加载的库文件格式是SGX预期的飞地传递方法，已经包含了加载算法的非正式规范。我们希望非正式加载规范能作为规范的起点，这些规范规定了用于从.so和.dll文件创建enclave的SGX指令的确切序列。
如3.3.2所述，飞地的测量是使用安全哈希算法计算的，因此系统软件只能通过遵循飞地作者指定的精确指令序列来构建与预期测量相匹配的飞地。

SGX的设计使用了256位的SHA-2 [21]安全哈希函数来计算其测量值。SHA-2是一个分组哈希函数（3.1.3），它对64字节的分组进行操作，使用32字节的内部状态，并产生32字节的输出。每个飞地的测量都存储在飞地SECS的MRENCLAVE区域中。32字节字段存储256位SHA-2安全哈希函数的内部状态和最终输出。

5.6.1 度量ECREATE

ECREATE指令首先使用256位SHA-2初始化算法在新创建的SECS中初始化MRENCLAVE字段，然后使用表16所示的64字节分组扩展散列。（初始化哈希值32字节，然后与其他三个字段一起存放在MRENCLAVE，64字节）

飞地的测量不包括BASEADDR。遗漏是有意的，因为它允许系统软件在满足ELRANGE范围限制（5.2.1）的主机进程内的任何虚拟地址加载飞地，而不更改度量。该特性可以与一个编译器结合起来，生成与位置无关的飞地代码，以获得可重新定位的飞地。
飞地的测量包括SSAFRAMESIZE域，这保证了由AEX创建、EENTER（5.4.1）和ERESUME（5.4.4）使用的ssa（5.2.5）具有飞地作者预期的大小。将这个字段排除在飞地的测量之外，将允许恶意的飞地加载器试图通过指定比飞地的作者预期更大的SSAFRAMESIZE来攻击飞地的安全检查，这可能导致AEX编写的SSA内容覆盖飞地的代码或数据。

5.6.2 度量Enclave属性

飞地的度量不包括飞地属性（5.2.2），这些属性在SECS中的ATTRIBUTES字段中指定。相反，它被直接包含在认证签名所涵盖的信息中，这将在5.8.1中进行讨论。
SGX软件认证肯定需要覆盖飞地的属性。例如，如果不覆盖XFRM（5.2.2,5.2.5），那么恶意的飞地加载器可能试图通过将XFRM设置为一个值来改变飞地指令语义的架构扩展来破坏飞地的安全检查，但仍然产生适合SSAFRAMESIZE的XSAVE输出。

5.2.2节是enclave的属性：enclave的执行环境严重的受enclave SECS中ATTRIBUTES的值的影响。SECS的字段ATTRIBUTES里包含子字段：DEBUG、XFRM、MODE64BIT。XFRM字段表示当enclave代码执行时XCR0的值。
执行上下文的大小取决于XSAVE所使用的requested-feature bitmap（RFBM）。一个飞地中的所有代码都使用相同的RFBM，该RFBM在XFRM飞地属性（5.2.2）中声明。为SSA指定的每个SSA保留的EPC页数必须足够大，以适合XFRM指定的feature bitmap的XSAVE输出。

从安全的角度来看，应用于属性SECS字段的特殊处理似乎值得怀疑，因为它给软件认证验证器增加了额外的复杂性，这意味着有更多的利用bugs的机会。这个决定也增加了SGX软件认证设计的复杂性，该认证设计见5.8。
尽管有上述的担忧，SGX设计决定走这条路线的最可能的原因是希望能够使用单一的度量来代表一个飞地，可以利用一些架构扩展，但也可以在没有它们的情况下执行其任务。
例如，考虑一个使用OpenCV等库执行图像处理的飞地，该库具有针对SSE和AVX优化的例程，但也包括不具有这些功能的处理器的通用回退。飞地的作者可能希望允许飞地加载器将位1（SSE）和位2（AVX）设置为真或假。如果属性（扩展为XFRM）是飞地度量的一部分，飞地作者将必须指定飞地有4个有效的度量。一般来说，允许独立使用n个架构扩展将导致$2^n$个有效的度量。

enclave的度量里没有ATTRIBUTES字段，但是其在软件认证的认证签名中包含。

5.6.3 度量EADD

EADD指令使用64字节的分组扩展了在MRENCLAVE中的SHA-2哈希值，如表17所示。

ENCLAVEOFFSET=PAGEINFO中的LINADDR字段-SECS中的BASEADDR字段

测量中包含的地址是期望在其中将EADDed页面映射到飞地的虚拟地址空间中的地址。这确保了系统软件根据飞地作者的规范设置飞地的虚拟内存布局。如果恶意的飞地加载器试图错误地设置飞地的布局，可能是为了发起主动地址转换攻击（3.7.2），所加载的飞地的度量将与飞地的作者所期望的度量不同。
新创建的页面的虚拟地址是相对于该飞地的ELRANGE的开始来测量的。换句话说，测量中包含的值是 LINADDR - BASEADDR。这使得飞地的测量对BASEADDR的变化无关，这对于可重新定位的飞地是可取的。测量相对地址仍然保留了ELRANGE内关于内存布局的所有信息，因此不会对安全产生负面影响。
EADD还度量提供给EADD的SECINFO结构（5.3.2）的前48个字节，其中包含页面类型（PT）和用于初始化页面的EPCM条目的访问权限（R、W、X）字段值。通过与上面相同的参数，在度量中包含这些值可以保证通过系统软件构建正在加载的enclave的内存布局与enclave作者期望的相匹配。
上面提到的EPCM字段值在SECINFO结构中占用不到一个字节，其余的字节被保留，并期望初始化为零。这为未来的SGX功能留出了大量的扩展空间。
表17中最值得注意的遗漏是用于初始化新创建的EPC页面的数据。因此，EADD提供的测量数据保证了飞地的内存布局将在所需的虚拟地址上分配具有指定访问权限的页面。但是，度量值并不包括在这些页面中加载的代码或数据。
例如，EADD的测量数据保证了一个飞地的内存布局由三个可执行页面和五个可写的数据页面组成，但它不能保证任何代码页面包含由该飞地的作者提供的代码。

这里保证在相应的虚拟地址上分配相应的访问权限的页面。

5.6.4 度量EEXTEND

EEXTEND指令的存在仅仅是为了测量在飞地的EPC页面中加载的数据。该指令读取一个虚拟地址，并使用表18中的5个64字节块扩展了飞地的测量散列，这有效地保证了飞地内存中256字节数据块的内容。

在检查EEXTEND的细节之前，我们注意到，SGX的安全保证只有在测量该飞地的关键页面的内容时才成立（即在度量enclave内容之前，先度量创建enclave页面时的元数据：SECS、EPCM等的内容）。例如，只有在测量了所有线程控制结构（TCS，5.2.4）页面的内容时，EENTER（5.4.1）才保证在飞地的代码中执行受控的跳转。否则，恶意飞地加载器可以在构建飞地时更改TCS中的OENTRY字段（5.2.4,5.4.1），然后恶意OS能够使用TCS在enclave代码中执行任意跳转。通过同样的论点，所有飞地的代码都应该通过EEXTEND来衡量。任何未被测量的代码片段都可以被恶意的飞地加载器替换。
考虑到这些缺陷，令人惊讶的是，SGX设计选择将EADD完成的虚拟地址空间布局度量与EEXTEND完成的内存内容度量解耦。
在第一次测试中，解耦似乎只有一个好处，即能够在构建一个飞地时将未测量的用户输入加载到一个飞地中。然而，这一好处只能转化为一个微小的性能改进，因为飞地也可以被设计为在初始化后从不受信任的DRAM复制用户输入。与此同时，解耦也开启了依赖一个没有提供有意义的安全保证的飞地的可能性，因为它没有通过EEXTEND调用来度量所有的重要数据。
然而，EADD/EEXTEND分离背后的真正原因是由SDM中的EINIT伪代码暗示的原因，它表明指令在执行计算密集的RSA签名检查时打开一个中断（2.12）窗口。如果在检查过程中发生中断，EINIT将出现错误代码，中断服务。对于处理器指令，这种非常不寻常的方法表明，SGX实现在允许其指令增加到中断处理进程中的多少延迟方面受到了限制。
鉴于以上问题，我们可以合理地得出结论，即引入了EEXTEND，因为使用256位SHA-2测量整个页面是相当耗时的，并且在EADD中这样做会导致指令超过SGX的延迟预算。需要达到某个延迟目标是对看似任意的256字节块大小的合理解释。
如果使用与构建今天的动态加载模块相同的工具编写飞地，EADD /EEXTEND分离不会导致安全问题，这些模块似乎是SGX设计的目标工作流。在这个工作流中，构建飞地的工具可以很容易地识别出需要测量的飞地数据。
从安全的角度来看，由哈希函数提供的消息块除了数据的内容外，还包括256字节块的地址是正确和有意义的。如果不包括该地址，一个恶意的飞地加载器可能会执行内存映射攻击（在3.7.2中描述的）。
更具体地说，恶意加载程序会在disclose的虚拟地址EADD errorOut的页面内容，在errorOut的虚拟地址EADD disclose页面内容，然后以错误的顺序EEXTEND页面。如果EEXTEND不包括被测量的数据块的地址，那么上述步骤将产生与正确构建的飞地相同的度量。
EETEND值得分析的最后一个方面是它对重定位飞地的支持。与EADD类似，通过EEXTEND测量的虚拟地址是相对于飞地的BASEADDR的。此外，由EEXTEND测量的唯一SGX结构是TCS。SGX的设计仔细地使用了表示包围区地址的所有TCS字段的相对地址，这些字段是OENTRY、OFSBASGX和OGSBASGX。

5.6.5 度量EINIT

EINIT指令（5.3.3）总结了飞地的构建过程。在一个飞地上成功调用EINIT后，飞地的内容被“密封”，这意味着系统软件不能使用EADD指令将代码和数据加载到飞地中，也不能使用EEXTEND指令更新飞地的测量。

EINIT在该飞地的SECS的MRENCLAVE字段上使用SHA-2最终终结算法（3.1.3）。在EINIT之后，该字段不再存储SHA-2算法的中间状态，而是存储安全哈希函数的最终输出。该值在EINIT完成后保持不变，并包含在SGX软件认证过程生成的认证签名中。

5.7 SGX Enclave Versioning Support

由可信平台模块（4.4）引入的软件认证模型（3.3）依赖于一个度量（5.6），它本质上是一个内容散列，用于识别容器内的软件。使用内容哈希作为标识的缺点是，保存同一软件的不同版本的容器的身份之间没有关系。
在实践中，基于安全容器的系统非常希望能够处理软件更新，而不需要在最初的软件证明过程中访问远程方。这需要能够在具有旧版本软件的容器和有软件更新的容器之间迁移秘密。这一要求意味着需要一个单独的识别系统，可以识别同一软件的两个版本之间的关系。
SGX支持在代表同一软件的不同版本的飞地之间的秘密迁移，如下图所示。

秘密迁移特性依赖于一个one-level证书层次结构，其中每个enclave author都是一个Certificate Authority，每个enclave都收到一个来自其author的证书。这些证书必须被格式化为Signature Structure（SIGSTRUCT），这在5。7.1中有描述。这些证书中的信息是5.7.2中提出的enclave身份方案的基础，该方案可以识别同一软件的不同版本之间的关系。
EINIT指令检查目标enclave的证书，并使用其中的信息来填充描述该enclave的基于证书的身份的SECS字段，此过程在5.7.4中总结了。
最后，实际的秘密迁移过程是基于由EGETKEY指令实现的密钥派生服务，详见5.7.5。发送enclave使用EGETKEY指令根据其身份获得一个对称密钥，用密钥加密他的秘密，并将加密的秘密交给不受信任的系统软件。接收enclave将发送enclave的身份传给EGETKEY，获得与上面相同的对称密钥，并使用该密钥对从系统软件接收到的秘密进行解密。
从EGETKEY获得的对称密钥可以与加密原语一起使用，以保护被不可信的系统软件迁移到另一个飞地时的一个飞地机密的机密性和完整性。但是，对称密钥不能单独用来提供新鲜度保证，因此秘密迁移会受到重放攻击。当正在迁移的秘密是不可变的时，例如当这些秘密是通过软件认证获得的加密密钥时，这是可以接受的。

每个enclave都有一个证书，该证书由其作者颁布，证书结构为SIGSTRUCT。EINIT指令检查每个enclave的证书是否合法。
证书中的信息是为了可以识别同一软件的不同版本之间的关系，更方便的实现同一软件不同版本之间的秘密迁移。

5.7.1 Enclave Certificates

SGX的设计要求每个enclave都有一个由其author颁发的证书，该要求由EINIT指令强制执行，并拒绝在没有有效证书的enclave上操作。
SGX实现使用格式化为Signature Structures（SIGSTRUCT）的证书，这些证书打算由一个enclave构建toolchain生成，如下图所示。

一个SIGSTRUCT证书由元数据字段组成，其中最有趣的在表19，以及一个保证元数据真实性的RSA签名，其格式如表20所示，这些字段的语义将在下面的章节出现。

ISVPRODID：区分同一私钥签名的模块；ISVSVN：区分同一模块的版本；VENDOR：区分Intel enclaves

enclave证书必须由RSA签名算法签名，它遵循RFC 3447，使用256位SHA-2作为减少输入大小的哈希函数，以及PKCS #1 v1.5中描述的填充方法，如图45所示。

SGX实现只支持3072位RSA密钥，其公共指数位3.密钥大小的选择可能是为了满足FIPS的建议，该建议使SGX有资格在美国政府的应用程序中使用。公共指数3提供了一个简化的签名验证算法，并在6.5中进行了讨论。简化的算法还需要RSA签名中的字段Q1和Q2，这也在6.5中描述。

5.7.2 Certificate-Based Enclave Identity

一个enclave身份由其证书中的三个字段决定：用来签名证书所使用的RSA密钥的模数（MODULUS），enclave的产品ID（ISVPRODID）和安全版本号（ISVSVN）。
用于颁发证书的RSA公钥标识了该enclave的作者。所有用于颁发飞地证书的RSA密钥必须将公共指数设置为3，因此它们只通过它们的模数来区分。SGX不使用一个key的整个模量，而是使用一个模量的256位SHA-2哈希。 这被称为签名者度量（signer measurement，MRSIGNER），与enclave度量（MRENCLAVE）的名称相似，enclave度量是用于识别飞地内容的SHA-2 哈希值。
SGX的实现依赖于一个硬编码的MRSIGNER值来识别英特尔颁发的证书。拥有由intel颁发的证书的飞地可以获得额外的特权，这将在5.8中进行讨论。
enclave作者可以使用相同的RSA密钥为代表不同软件模块的enclave颁发证书。每个模块通过唯一的Product ID（ISVPRODID）值标识。相反地，所有enclaves假设代表同一软件模块的不同版本，这些enclave的证书具有相同的ISVPRODID并被相同的RSA密钥颁发（因此具有相同的MRENCLAVE）。
表示一个模块的不同版本的飞地可以有不同的安全版本号（SVN）。SGX的设计不允许将秘密从SVN较高的飞地迁移到SVN较低的飞地。此限制旨在帮助分发安全补丁，如下所示。
如果在飞地中发现了安全漏洞，作者可以发布具有更高SVN的修补版本。随着用户的升级，SGX将促进秘密从飞地的脆弱版本迁移到修补版本。一旦用户的秘密被迁移，SGX中的SVN限制将抵御任何基于构建脆弱的飞地版本并使用它来读取迁移的秘密的攻击。
添加功能的软件升级不应该伴随着SVN的增加，因为SGX允许秘密在具有匹配的SVN值的飞地之间自由地迁移。如上所述，只有在发现安全漏洞时，软件模块的SVN才会增加。SIGSTRUCT只为ISVSVN字段分配2个字节，即65,536个可能的SVN值。如果一个大团队（错误地）设置了一个连续的构建系统，为它产生的每个软件构建分配一个新的SVN，并且每个代码更改都会触发一个构建，那么这个空间可能会耗尽。

基于证书的enclave识别是通过RSA密钥的模数（MODULUS），enclave的产品ID（ISVPRODID），安全版本号（ISVSVN）决定。其中同一软件的不同版本的MODULUS和ISVPRODID相同，ISVSVN不同。SVN高的秘密不允许迁移至SVN低的enclave。当软件有漏洞时，才新创建一个安全版本号。同一软件相同产品ID和相同的安全版本号之间，enclave的秘密可以自由的迁移。

5.7.3 CPU Security Version Numbers

SGX实现本身有一个安全版本号（CPUSVN），除了飞地的身份信息外，它还在由EGETKEY实现的密钥派生过程中使用。CPUSVN是一个128位的值，根据开发文档的说法，它反映了处理器的微码更新版本。
开发文档没有描述CPUSVN的结构，但它指出，使用整数比较来比较CPUSVN值是没有意义的，而且只有一些CPUSVN值是有效的。此外，cpusvn承认它的排序关系与飞地svn之间的排序关系具有相同的语义。具体来说，SGX实现将考虑所有具有svn较低的SGX实现由于安全漏洞而受到损害，并且不信任它们。
一项SGX专利[138]公开了，CPUSVN是一个表示组成SGX实现的各种组件的svn的小整数的连接。这个结构与开发文档中所做的所有语句都相一致。

5.7.4 Establishing an Enclave’s Identity

当EINIT指令为代码执行准备了一个飞地时，它还设置了构成该飞地的基于证书身份的SECS字段，如图77所示。

EINIT要求颁发给飞地的SIGSTRUCT证书的虚拟地址，并使用证书中的信息来初始化飞地的SECS中的基于证书的身份信息。在使用证书中的信息之前，EINIT首先验证其RSA签名。SUGSTRUCT字段Q1和Q2，以及RSA的指数3，促进了一个简化的验证算法，这将在6.5中进行讨论。
如果发现SIGSTRUCT证书签名正确，EINIT将遵循以下几段中讨论的步骤，以确保证书被颁发给正在初始化的飞地。一旦检查完成，EINIT计算MRSIGNER，即SIGSTRUCT中模量域的256位SHA-2散列，并将其写入飞地的SECS。EINIT还将ISVPRODID和ISVSVN字段从SIGSTRUCT复制到飞地的SECS中。如5.7.2中所述，这些字段构成了该飞地的基于证书的身份。
在SIGSTRUCT中验证RSA签名后，EINIT将签名的填充复制到飞地的SECS中的PADDING字段中。图45中概述的PKCS #1 v1.5填充方案不涉及随机性，因此填充对于所有飞地应该具有相同的值。
EINIT执行一些检查，以确保正在初始化的飞地确实得到了所提供的SIGSTRUCT的授权。最明显的检查是确保SIGSTRUCT中的ENCLAVEHASH值等于飞地的度量，它存储在飞地的SECS中的MRENCLAVE字段中。
然而，MRENCLAVE并不包括飞地的属性，它们存储在SECS的ATTRIBUTES字段中。如5.6.2中讨论的，从MRENCLAVE中省略ATTRIBUTES有助于编写具有优化实现时可以使用架构扩展，并且具有在没有扩展的cpu上工作的回退实现。当使用XFRM（5.2.2,5.2.5）属性中的各种值进行构建时，这样的飞地可以正确地执行。同时，允许系统软件在ATTRIBUTES字段中使用任意值将会危及SGX的安全保证。
当一个飞地使用软件认证（3.3）来获取对秘密的访问时，用于构建它的属性值将包含在SGX认证签名（5.8）中。这使认证过程中的远程当事方有机会拒绝使用不希望的属性值构建的飞地。但是，当使用基于证书的身份所促进的迁移过程获得秘密时，没有一个远程当事方可以检查飞地的属性。

5.8 SGX Software Attestation

SGX实施的软件认证方案遵循3.3节中概述的原则。启用SGX的处理器计算在每个enclave中加载的代码和数据的度量，这与TPM计算的度量类似。enclave内的软件可以启动一个生成SGX证明签名的过程，该签名包括enclave的度量和飞地消息。
SGX的认证签名中使用的密码原语太复杂， 无法在硬件中实现，因此签名过程由Intel发布的特权Quoting Enclave执行，它可以访问SGX认证密钥。该enclave将在5.8.2中进行讨论。
将签名功能推到Quoting Enclave,需要在接受软件认证的enclave和Quoting enclave之间建立一个安全的通信通道。SGX设计通过一个本地认证机制解决了这个问题，一个enclave可以使用该机制向由同一启用SGX的CPU托管的任何其他enclave证明其身份。该方案是由EREPORT指令实现，在5.8.1中描述。
在启用了SGX的处理器离开工厂时，Quoting enclave所使用的SGX认证密钥并不存在。认证密钥稍后将提供，使用一个进程，该进程包含一个由Intel发布的Provisioning enclave和两种特殊EGETKEY密钥类型。这个过程的公开细节总结见5.8.2。
SGX启动enclave和EINITTOKEN结构将在5.9中讨论。

总结：对加载到enclave里的数据和代码进行度量，并对计算的enclave度量和enclave消息进行签名，想要认证一个enclave是否是真是CPU创建的，或者检测加载到enclave里的代码和数据是否被篡改，验证方可以对签名进行验证。

5.8.1 Local Attestation

一个enclave向另一个目标enclave证明它的身份，通过下图中的EREPORT指令。SGX指令生成一个认证报告（REPORT），该报告加密地将enclave提供的信息和与enclave基于度量和基于证书的身份绑定。加密绑定是通过一个MAC标签完成的，该标签使用的对称秘钥只在目标enclave和SGX实现之间共享。

SGX指令EREPORT生成一个证明报告，该指令利用对称加密AES-CMAC算法，将enclave的消息与其基于度量的身份和基于证书的身份进行加密形成MAC标签。对称秘钥在目标enclave与SGX之间共享。

EREPORT指令从enclave的SECS中读取当前enclave的身份信息，并且使用它来填充REPORT结构。特别是，EREPORT复制SECS字段，这些字段指示enclave的度量（MRENCLAVE），基于证书的身份（MRSIGNER，ISVPRODID，ISVSVN），和属性（ATTRIBUTES）。这个认证报告也包含SGX实现的SVN（CPUSVN）和由enclave提供的一个64字节的消息。
接收到认证报告的目标enclave可以说服自己相信该报告的真实性，如下图所示，真个报告的真实性证明是其MAC标签。验证MAC所需的密钥只能通过目标enclave获得，通过询问EGETKEY来派生出一个Report key。开发手册MAC标签是使用基于分组加密的MAC（CMAC），但是没有指定底层加密，SGX的一篇论文指出，CMAC是基于128位的AES的。

由EGETKEY返回的Report key是来自CPU中嵌入的一个秘钥，并且这个key的原材料包括目标enclave的度量。目标enclave可以确定报告中的MAC标签是由SGX实现产生，原因如下。底层秘钥派生的密码属性和MAC算法确保只有SGX实现可以产生MAC标签，因为只有这一个SGX实体可以访问处理器的密钥，一个攻击者不可能在没有处理器秘钥的情况下来派生Report key。SGX的设计保证了由EGETKEY生成的密钥依赖于enclave的度量值，所以只有目标enclave才能获得用于在报告中生成的MAC标签的key。

假设enclave A和enclave B之间要进行身份认证，首先enclaveB作为目标enclave，A向B证明身份的真实性，流程可简单概括如下：1）A调用EREPORT指令生成一个包含A信息MAC标签的Report。具体的，使用对称加密算法将A的度量、证书身份、SVN等加密形成一个MAC标签，并将MAC标签和以上信息一同形成一个Report发送给B。注意：这个加密密钥生成原料包括目标enclave B的度量等信息。这里是确保只有目标enclave可以获得Report key，来验证报告中MAC标签的真实性。2）B收到Report后，调用EGETKEY指令，来获得验证MAC标签的Report key。其中Report key的原料也是包含B的度量值等信息，确保只有B能获得Report key。通过对称秘钥Report key来解密MAC标签，验证解密后的信息和Report内的信息是否一致。
对称秘钥生成是由CPU内嵌的密钥派生的，只有SGX的特定实体可以访问该CPU密钥，所以，攻击者不能在没有CPU密钥的情况下产生Report key。所以B可以确定该Report是由SGX实体产生的，因此可以确保A的真实身份，是运行在同一个CPU上。在这节刚开始介绍对称秘钥仅有目标enclave B和SGX知晓，那么A不知晓对称秘钥，怎么加密MAC的呢？我理解的是对称秘钥由A和B知晓，相当于通过SGX EGETKEY来协商秘钥。如有理解有误，回头再看看5.7节再修改该部分。

当调用KEYNAME设置为与Report key关联的值时，EREPORT和EGETKEY使用相同的密钥派生进程。因此，EREPORT需要一个Report Target Info（TARGETINFO）结构的虚拟地址，该结构包含目标enclave的基于度量的身份和属性。
当得到一个Report key时，EGETKEY的行为与seal key的行为略有不同，如下图所示，秘钥生成材料从不包含与enclave的基于证书身份（MRSIGNER、ISVPRODID、ISVSVN）对应的字段，并且忽略在KEYREQUEST结构中的KEYPOLICY字段。因此，该报告只能由目标enclave进行验证核实。
此外，用于密钥生成的SGX实现的SVN（CPUSVN）值由当前CPUSVN决定，而不是从Key Request结构中读取，因此，SGX实现升级，增加了CPUSVN使所有未完成的报告无效。鉴于CPUSVN的增加与安全修复相关联，5.7.2中的参数表明，此限制可能会降低SGX实现中漏洞的影响。
最后，EREPORT将密钥生成材料中的KEYID字段设置为SGX配置寄存器（CR_REPORT_KEYID）的内容，该寄存器在SGX初始化时以随机值初始化。KEYID值也保存在认证报告中，但是MAC标签不包括它。

5.9 SGX enclave Launch Control

在enclave由EINIT初始化之前必须由Launch enclave做批准决定。
SGX专利[110,138]明确地披露了，启动飞地的引入是为了确保每个飞地的作者与英特尔有业务关系，并实施了一个软件许可系统。§5.9.2简要地讨论了其含义，如果这是真的的话。
本节的其余部分认为，Launch enclave应该从SGX的设计中删除。5.9.3解释了LE不需要强制执行计算机所有者的启动控制策略，并得出结论，只有当LE强制执行对计算机所有者有害的策略时，它才有意义。§5.9.4揭穿了一个飞地可以托管恶意软件的神话，这很可能被用来证明LE辩护。§5.9.5认为，反病毒（AV）软件与飞地并不不兼容，进一步反驳了英特尔需要积极监管在飞地内运行的软件的理论。

5.9.1 Enclave Attributes Access Control

SGX的设计要求所有的飞地都要由一个启动飞地（LE）进行审查，这只是在英特尔的官方文档中简要提到的。没有指定它的行为或与系统软件的接口。我们推测，英特尔还没有透露关于LE，因为它在执行软件授权中的作用，这将在5.9.2中讨论。本节抽象化了许可方面，并假定LE强制执行了一个黑盒启动控制策略。
LE通过使用图85所示的过程发布EINIT令牌（EINITTOKEN）来批准一个飞地。图85是LE计算EINITTOKEN的过程。
EINITTOKEN结构包含基于批准飞地的测量（5.6）和基于证书（5.7.2）身份，就像本地认证报告（5.8.1）一样。这个令牌由EINIT（5.3.3）检查，它拒绝使用不正确的令牌初始化飞地。
虽然EINIT令牌由不受信任的系统软件处理，但它的完整性由一个MAC标记（3.1.3）保护，该标记使用从EGETKEY获得的启动密钥进行计算。EINIT实现遵循与EGETKEY相同的密钥派生过程，以说服自己，提供给它的EINIT令牌确实是由一个能够访问启动密钥的LE生成的。
SDM没有记录用于赋予标记结构完整性保证的MAC算法。但是，EINIT伪代码使用与电子报告伪代码用来创建报告结构的MAC标记相同的函数来验证令牌的MAC标记。由此可见，可以重用5.8.1中的推理，从而得出结论，EINITTOKEN结构是使用具有128位密钥的AES-CMAC制造的。
EGETKEY指令仅为LAUNCHKEY属性设置为true的飞地派生启动密钥。启动密钥使用与密封密钥（5.7.5）相同的过程获得。衍生材料包括当前飞地的版本控制信息（主动和ISVSVN），但它不包括传达飞地身份的主要域，即MRSIGNER和MRENCLAVE。其余的衍生材料遵循与密封秘钥所使用的材料相同的规则。
EINITTOKEN结构包含已批准的飞地的身份（MRENCLAVE和MRSIGNER）和已批准的飞地属性（ATTRIBUTES）。也包括用于Launch key派生的信息：LE的产品ID（ISVPRODIDLE）、SVN（ISVSVNLE）、MASKEDATTRIBUTESLE。