Intel SGX背景、其他可信计算技术和TEE技术（翻译自Intel SGX Explained）

强烈推荐《Intel SGX Explained》

作者对Intel SGX进行了详细的教科书般的讲解

Costan V, Devadas S. Intel SGX Explained[J]. IACR Cryptol. ePrint Arch., 2016, 2016(86): 1-118.

http://css.csail.mit.edu/6.858/2020/readings/costan-sgx.pdf

SGX背景

如下图所示，远程计算的安全问题是在不受信任⽅拥有和维护的远程计算机上执⾏软件的问题，需要具有⼀定的完整性和机密性保证。在⼀般情况下，安全的远程计算是⼀个尚未解决的问题。完全同态加密 Fully Homomorphic Encryption解决了有限的⼀系列计算问题，但性能开销不切实际。

 

如下图所示，英特尔的Software Guard Extensions（SGX）是⼀系列可信计算设计中的最新版本，旨在通过利⽤远程计算机中的可信硬件来解决安全的远程计算问题，可信硬件建⽴⼀个安全容器，远程计算服务用户将所需的计算和数据上载到安全容器中，受信任的硬件在执⾏计算时会保护数据的机密性和完整性。

 

SGX依赖于软件认证，就像它的前身TPM和TXT一样，下图所示的认证向⽤户证明它正在与在受信任硬件托管的安全容器中运⾏的特定软件进⾏通信。认证是加密签名，⽤于证明安全容器内容的哈希值。因此，远程计算机的所有者可以在安全容器中加载任何软件，但是远程计算服务⽤户将拒绝将其数据加载到内容哈希值与预期值不匹配的安全容器中。

 

远程计算服务⽤户根据受信任的硬件制造商创建的认可证书验证⽤于产⽣签名的证明密钥，证书指出，证明密钥仅是可信硬件知道的，并且仅⽤于证明⽬的。

SGX在其前身中脱颖⽽出，其认证覆盖的代码量位于使⽤硬件保护的系统的可信计算库（TCB）中。TPM原始设计产⽣的证明涵盖了计算机上运⾏的所有软件，⽽TXT证明涵盖了VMX虚拟机中的代码。在SGX中，一个enclave（安全容器）仅在计算中包含私有数据以及对其进⾏操作的代码。

例如，可以通过让⽤户上传加密的图像来实现对机密医学图像执⾏图像处理的云服务，⽤户可以将加密密钥发送到enclave内运⾏的软件，enclave将包含⽤于解密图像的代码、图像处理算法以及⽤于加密结果的代码。接收上传的加密图像并存储它们的代码将留在enclave之外。

启⽤SGX的处理器通过将enclave的代码和数据与外部环境（包括操作系统和管理程序以及连接到系统总线的硬件设备）隔离开来，保护enclave内部计算的完整性和机密性，同时，SGX模型仍然与Intel体系结构中的传统软件分层兼容，在该体系结构中，OS内核和虚拟机管理程序管理计算机资源。

这项⼯作讨论了SGX的原始版本，也称为SGX1，尽管SGX 2为enclave作者提供了⾮常有⽤的改进，但从设计和实现的⻆度来看，这只是⼀个很⼩的改进。

SGX Lightning Tour

SGX预留了⼀个内存区域，称为处理器预留内存PRM，CPU保护PRM免受所有⾮enclave内存访问，包括内核、虚拟机管理程序和SMM访问，以及来⾃外围设备的DMA访问。

PRM拥有Enclave⻚⾯缓存EPC，该⻚⾯缓存由4 KB⻚⾯组成，⽤于存储Enclave代码和数据。不受信任的系统软件负责将EPC⻚⾯分配给enclave，CPU在enclave⻚⾯缓存元数据EPCM中跟踪每个EPC⻚的状态，以确保每个EPC⻚都完全属于⼀个enclave。

enclave中的初始代码和数据由不受信任的系统软件加载，在加载阶段中，系统软件要求CPU将不受保护的内存（PRM外部）中的数据复制到EPC⻚⾯中，并将这些⻚⾯分配给正在设置的enclave。因此，初始enclave状态是系统软件已知的。

将所有enclave的⻚⾯加载到EPC中后，系统软件会要求CPU将安全区标记为已初始化，此时应⽤程序软件可以在enclave内运⾏代码。Enclave初始化后，将禁⽤上述加载⽅法。

加载enclave时，它的内容是由CPU哈希加密的，enclave初始化后，哈希值将最终确定，并成为enclave的测量哈希值。

远程⽅可以进⾏软件认证过程，以确保⾃⼰正在与具有特定度量哈希且在安全环境中运⾏的enclave通信。

执⾏流只能通过特殊的CPU指令进⼊enclave，这与从⽤户模式切换到内核模式的机制类似，enclave执⾏始终在保护模式下（第3环）发⽣，并使⽤OS内核和虚拟机管理程序设置的地址转换。

为了避免泄漏私有数据，正在执⾏enclave代码的CPU不会直接处理中断、故障（例如⻚⾯错误）或VM退出，CPU⾸先执⾏异步enclave 退出（AEX），以从enclave代码切换到环3代码，然后为中断、故障或VM出⼝提供服务。CPU通过将CPU状态保存到enclave内的预定义区域中来执⾏AEX，然后将控制权转移到enclave外的预先指定的指令中，⽤合成值替换CPU寄存器。

将EPC⻚⾯分配到enclave的操作委托给OS内核或管理程序，OS通过特殊的Ring 0 CPU指令将其分配决策传达给SGX实现。操作系统还可以将EPC⻚⾯驱逐到不受信任的DRAM中，然后使⽤专⽤的CPU指令将其重新加载。SGX使⽤加密保护来确保被逐出的EPC⻚存储在不受信任的内存中时的机密性，完整性和新鲜性。

SGX相关技术进展

IBM 4765 安全协处理器 

安全协处理器在防篡改环境中囊括了一整套计算机系统，包括CPU、密码加速器、缓存、DRAM和I / O控制器。安全协处理器边界保护包含抗攻击的硬件（例如Faraday cage）以及能检测篡改的传感器阵列，当检测到攻击时，安全协处理器会破坏它保存的秘密。这种方法具有能很好地抵御物理攻击。但相对于一套普通的计算机系统而言，这种抗篡改的边界保护成本非常昂贵。

IBM 4758及其最新的继任者IBM 4765（如下图所示）是安全协处理器中的典型例子，4758经过认证可以承受FIPS 140-1 第4级的物理攻击，⽽4765符合FIPS 140-2 第4级的严格要求。

 

4765的安全性主要源于这种物理隔离，通过使用与应用程序处理器完全分离的专用服务处理器，可以保护（4765的）系统软件免受（主处理器上的）应用程序软件的攻击，专用总线逻辑上阻止（主处理器上的）应用程序处理器访问（4765的）特权资源，例如battery-backed内存存储的系统软件秘密。

4765实现软件认证，协处理器的证明密钥存储在battery-backed内存中，该内存只能由服务处理器访问。当重置的时候，服务处理器将执行存储在ROM中的第⼀阶段的bootloader，该bootloader将测量并加载系统软件。系统软件依次测量存储在NVRAM中的应用程序代码，并将其加载到应用程序处理器可访问的DRAM芯⽚中，系统软件为协处理器内部加载的应⽤程序提供证明服务。

ARM TrustZone

ARM的TrustZone是⼀组硬件模块。从概念上来说，TrustZone可在承载着安全容器的安全世界和运行着不可信软件堆栈的普通世界之间划分系统资源，TrustZone文档描述其半导体知识产权核心（IP块）及其组成的安全属性，反映了ARM是IP核心提供者⽽不是芯片制造商的事实。因此，系统中仅存在TrustZone IP块不足以确定系统在特定威胁模型下是否安全。下图说明了使⽤TrustZone IP模块的智能⼿机⽚上系统（SoC）设计。

 

TrustZone使⽤⼀个信号来扩展AMBA AXI系统总线中的地址线，该信号指⽰访问是属于安全还是常规（⾮安全）领域。执⾏代码时，包含TrustZone的“安全扩展”的ARM处理器内核可以在正常环境和安全环境之间切换，内核执⾏的每个总线访问中的地址反映了内核当前正在执⾏的环境。

TrustZone处理器中的复位电路将其置于安全模式，并将其指向存储在⽚内ROM中的第⼀级引导程序，TrustZone的TCB包含此引导程序，该引导程序初始化平台，设置TrustZone硬件以保护安全容器不受不信任软件的侵害，并加载普通⽤户的引导程序。安全容器还必须实现⼀个监视器，该监视器执⾏在两个环境之间转换执⾏核⼼所需的上下⽂切换。 监视器还必须处理硬件异常（例如中断），并将其路由到适当的环境。

TrustZone设计使安全世界的监视器可以不受限制地访问正常世界，因此该监视器可以在两个世界中的软件之间实现进程间通信（IPC），监视器可以使⽤安全和⾮安全地址发布总线访问权限，通常，安全世界的软件可以危害正常世界软件堆栈中的任何级别。例如，通过翻转寄存器中的⼀位，安全容器的软件可以跳⼊正常世界中的任意位置，正常情况下不受信任的软件只能通过跳转到监视器内部定义明确的位置的指令来访问安全世界。

从概念上讲，每个TrustZone CPU核心为安全和正常世界提供单独的地址转换单元，这是通过两个页表基址寄存器来实现的，并且通过让page walker使⽤与CPU核心的当前世界相对应的页表基址来实现，页表条⽬中的物理地址已扩展为包括要在AXI总线上发布的安全位的值。通过使CPU内核将地址转换结果中的安全位强制为零（对于正常的世界地址转换），可以保护安全世界不受不信任软件的侵害。 由于安全容器管理⾃⼰的页⾯表，因此不受信任的OS的页⾯错误处理程序⽆法直接观察其内存访问。

信任TrustZone的硬件模块（例如缓存）可以使⽤每个总线访问中的安全地址位来实现世界之间的隔离。例如，TrustZone的缓存将安全位存储在每条缓存⾏的地址标签中，从⽽有效地为运⾏在不同环境中的软件提供了完全不同的内存空间视图，该设计假定存储空间在两个环境之间进⾏了划分，因此不会发⽣混叠。

TrustZone⽂档描述了两种TLB配置，如果期望在世界之间进⾏许多上下⽂切换，则可以将TLB IP块配置为在地址标签中包含安全位，或者，只要监视器在切换上下⽂时刷新TLB，就可以从TLB中省略安全位。

预计不占⽤TrustZone地址位的硬件模块将通过实现简单分区技术的IP内核连接到AXI 总线。例如，TrustZone内存适配器（TZMA）可⽤于将⽚上ROM或SRAM划分为安全区域和普通区域，⽽TrustZone地址空间控制器（TZASC）则可对DRAM控制器提供的存储空间进⾏分区，拖曳到安全和正常区域。可识别TrustZone的DMA控制器拒绝来⾃引⽤安全世界地址的常规世界的DMA传输。

因此，分析TrustZone系统的安全属性需要对连接到AXI总线的所有硬件模块的⾏为和配置有准确的了解。例如，TrustZone⽂档中描述的缓存不会在世界之间强制完全隔离，因为它们允许访问世界的内存以驱逐另⼀个世界的缓存⾏。 这使安全容器软件在正常情况下可以缓存来⾃不受信任软件的实时攻击。但是，获得TrustZone IP内核许可的硬件制造商不愿透露其设计的所有细节，从⽽使安全研究⼈员⽆法推理基于TrustZone的硬件。

TrustZone组件没有针对物理攻击的任何对策。但是，在信任处理器芯⽚封装的威胁模型下，TrustZone⽂档所说的系统不会受到物理攻击。AXI总线是在连接SoC设计中的组件，因此攻击者⽆法利⽤它。TrustZone⽂档建议将安全环境中的所有代码和数据存储在⽚上SRAM中，可以保护不受物理攻击，但是，这种⽅法对安全容器的功能提出了重⼤限制，因为⽚上SRAM⽐相同容量的DRAM芯⽚贵很多个数量级。

TrustZone的⽂档没有描述任何软件证明实施，但是，它确实概述了⼀种⽤于实现安全启动的⽅法，该⽅法是第一阶段的引导加载程序会针对公共密钥验证第二阶段的引导加载程序中的签名，该公共密钥的加密哈希被烧入片上一次性可编程（OTP）多晶硅熔丝中。通过将每个芯片的认证密钥存储在多元保险丝中，并让第一阶段的引导加载程序测量第二阶段的引导加载程序然后将其哈希存储在片上SRAM区域中，可以在相同组件的顶部构建硬件测量配给安全的世界。多熔丝将由TZMA IP块控制，这使它们只能被安全的世界访问。

The XOM Architecture

execute-only memory (XOM) 架构引⼊了在不受信任的主机软件管理的隔离容器中执⾏敏感代码和数据的⽅法，XOM概述了将容器的数据与其不受信任的软件环境隔离的机制，例如在处理中断之前将寄存器状态保存到受保护的内存区域。

XOM通过⽤拥有它的容器的标识符标记每条缓存⾏来⽀持多个容器，并通过禁⽌对与当前容器的标识符不匹配的缓存⾏进⾏内存访问来确保隔离，操作系统和不受信任的应⽤程序被视为属于具有空标识符的容器。

XOM还在处理器的内存控制器中引⼊了加密和HMAC功能的集成，以保护容器内存免受DRAM的物理攻击。加密和HMAC功能⽤于所有⾼速缓存⾏的逐出和提取，DRAM芯⽚中的ECC位⽤于存储HMAC值。

 

XOM的设计不能保证DRAM的新鲜度，因此其容器中的软件容易受到物理重放攻击。此外，XOM不能保护容器的内存访问模式，这意味着任何恶意软件都可以对容器中的软件执⾏缓存定时攻击。 最后，XOM容器在遇到硬件异常（例如页⾯错误）时会被破坏，因此XOM不⽀持页⾯调度。

XOM早于上述证明⽅案，⽽是依靠修改后的软件分发⽅案，每个容器的内容均使⽤对称密钥加密，该对称密钥也⽤作容器的标识。对称密钥又使⽤每个受信任来运⾏容器的CPU的公共密钥加密。通过将机密信息嵌⼊加密的容器数据中并使⽤它来对容器进⾏⾝份验证，可以确保容器的作者可以在可靠的软件上运⾏该容器。尽管从概念上讲⽐软件认证更简单，但是此⽅案不允许容器作者审核容器的软件环境。

The Trusted Platform Module (TPM)

可信平台模块（TPM）引⼊了软件证明模型，TPM设计不需要对CPU进⾏任何硬件修改，⽽是依靠辅助防篡改芯⽚。TPM芯⽚仅⽤于存储证明密钥和执⾏软件证明，由于TPM不依赖于CPU修改，因此已⼴泛部署在商⽤计算机上，但是，这种⽅法的代价是TPM具有⾮常弱的安全性保证。

TPM设计提供了⼀个隔离容器，涵盖了具有TPM芯⽚的计算机上运⾏的所有软件，认证签名中包含的度量范围涵盖了整个OS内核和所有内核模块，如设备驱动程序。但是，商⽤计算机使⽤各种各样的设备，并且其系统软件以不断增加的速度进⾏更新，因此不可能维护与⼀个受信任的软件相对应的可接受测量散列的列表。由于这个问题，尽管TPM的软件配置⼴泛，但并未在许多安全系统中使⽤。

TPM设计在技术上不受任何软件攻击的影响，因为它信任计算机上的所有软件。但是，基于TPM的系统容易受到可以物理访问计算机的攻击者的攻击，因为TPM芯⽚⽆法为计算机上的软件提供任何隔离，此外，TPM芯⽚从CPU接收软件测量结果，因此基于TPM的系统容易受到攻击者的攻击，攻击者可以利⽤CPU和TPM之间的通信总线。

最后，TPM的设计依赖于CPU上运⾏的软件来报告⾃⼰的加密哈希，重启计算机后，TPM芯⽚会重置存储在平台配置寄存器（PCR）中的测量值，TPM希望每个引导阶段的软件在下⼀个阶段以加密⽅式对软件进⾏哈希处理，然后将哈希发送给TPM。TPM更新PCR，以合并接收到的新哈希，如下图所示。任何时候的PCR值都反映了TPM到该点为⽌收到的所有软件哈希，这使得被测软件⽆法从测量中“删除”自身。

 

 

例如，⼤多数现代计算机上的固件都在统⼀可扩展固件接⼜（UEFI）规范中实现了平台初始化过程，每个平台初始化阶段都负责验证或测量实施下⼀阶段的固件，SEC固件会初始化TPM PCR，然后将PEI的测量结果存储到测量寄存器中。 反过来，PEI实施会测量DXE固件，并更新存储PEI哈希的测量寄存器，以解决DXE哈希问题，启动操作系统时，测量寄存器中的哈希值将解释⽤于启动计算机的所有固件。

不幸的是，整个测量⽅案的安全性取决于发送到TPM的第⼀个哈希必须是反映在第⼀个引导阶段运⾏的软件。TPM威胁模型明确确认了此问题，并假定负责加载第⼀阶段引导程序的固件已安全地嵌⼊主板中。 但是，⼏乎所有⽀持TPM的计算机都将其固件存储在闪存芯⽚中，该芯⽚可以在软件中重新编程，因此攻击者可以颠覆TPM的度量，攻击者可以重新刷新计算机的固件。

在最近的英特尔处理器上，通过使初始化微代码对计算机的固件（特别是UEFI固件中的PEI代码），进行哈希处理，然后将哈希值传递给TPM芯片，可以克服上述攻击，这是Intel Boot Guard的“ Measured Boot”功能。

⼤多数计算机制造商使⽤“验证启动”（也称为“安全启动”）⽽不是“测量启动”（也称为“受信任启动”），验证启动意味着处理器的微代码只能引导到PEI固件中，该固件包含签名，该签名是由烧⼊芯⽚电⼦保险丝中的密钥产⽣的，验证启动不会影响TPM上存储的度量，因此不会提⾼软件认证的安全性。

Intel’s Trusted Execution Technology (TXT)

英特尔的可信执⾏技术（TXT）使⽤TPM的软件认证模型和辅助防篡改芯⽚，但将安全容器内的软件减少为由CPU的硬件虚拟化功能托管的虚拟机。

TXT通过确保容器在运⾏时对整个计算机具有独占控制权，将容器内的软件与不受信任的软件隔离开，这是通过安全的初始化⾝份验证代码模块（SINIT ACM）来完成的，该模块在启动容器的VM之前可以有效地执⾏系统热复位。

 

TXT需要具有扩展寄存器集的TPM芯⽚。初始化TXT VM后，它会更新构成动态信任根度量（DRTM）的TPM寄存器，虽然TPM的SRTM寄存器仅在引导周期开始时复位，但每次启动TXT VM时，SINIT ACM都会复位DRTM寄存器。

TXT不实现DRAM加密或HMAC，因此像基于TPM的设计⼀样容易受到物理DRAM攻击。此外，早期的TXT实施容易受到攻击，其中恶意操作系统会对设备（例如⽹卡）进⾏编程，以执⾏对TXT容器使⽤的DRAM区域的DMA传输。 在最近的Intel CPU中，内存控制器集成在CPU芯⽚上，因此SINIT ACM可以安全地设置内存控制器，以拒绝将TXT内存作为⽬标的DMA传输。英特尔芯⽚组数据表记录了“英特尔TXT DMA保护范围” IIO配置寄存器。

早期的TXT实施⽆法衡量SINIT ACM，取⽽代之的是，执⾏TXT启动指令的微码通过硬编码的Intel密钥验证了代码模块包含RSA签名，如果发现漏洞，则不能撤销SINIT ACM签名，因此当SINIT ACM漏洞浮出⽔⾯时，必须修改TXT的软件证明。当前，SINIT ACM的加密哈希包含在证明度量中。

最后，由SINIT ACM执⾏的热复位不包括以系统管理模式（SMM）运⾏的软件。SMM专为固件使⽤⽽设计，并存储在受保护的存储区（SMRAM）中，⾮SMM软件不应访问该存储区。但是，SMM处理程序曾多次遭到攻击，并且获得SMM执⾏的攻击者可以访问TXT容器使⽤的内存。

The Aegis Secure Processor

Aegis安全处理器依赖操作系统中的安全内核来隔离容器，并在软件认证签名报告的度量中包括内核的加密哈希。“Design and Implementation of the AEGIS Single-Chip Secure Processor Using Physical Random Functions”文献认为，物理不可克隆功能（PUF）可⽤于为安全处理器赋予防篡改私钥，这是软件验证所必需的。PUF没有EEPROM的制造⼯艺缺陷，并且与电⼦熔断器相⽐，对物理攻击的抵抗⼒明显强得多。

Aegis依靠受信任的安全内核通过配置地址转换中使⽤的页表将每个容器与计算机上的其他软件隔离，安全内核是典型OS内核的⼦集，并处理虚拟内存管理、进程和硬件异常。由于安全内核是受信任代码库（TCB）的⼀部分，因此其加密哈希包含在软件证明度量中。安全内核使⽤处理器功能将⾃⾝与操作系统的不受信任的部分（例如设备驱动程序）隔离开。

Aegis存储控制器对⼀个存储范围内的⾼速缓存⾏进⾏加密，并对另⼀个存储范围内的⾼速缓存⾏进⾏HMAC加密，这两个内存范围可以重叠，并且可以由安全内核配置。由于这两个内存范围，存储控制器可以避免容器外部DRAM的加密操作的等待时间开销。Aegis是第⼀个不易受到物理重放攻击的安全处理器，因为它使⽤Merkle树结构来保证DRAM的新鲜度。通过使⽤⾼速缓存⾏的树节点增加L2⾼速缓存，可以⼤⼤减少Merkle树的等待时间开销。

Aegis的安全内核允许操作系统分页出容器内存，但可以验证分页操作的正确性。 安全内核使⽤与存储控制器相同的加密和Merkle树算法，以保证从DRAM换出的容器页⾯的机密性和完整性。该操作系统可以⾃由调出容器内存，因此可以按页⾯粒度了解容器的内存访问模式，Aegis容器也容易受到缓存定时攻击。

The Bastion Architecture

Bastion体系结构引⼊了使⽤受信任的管理程序来为运⾏在未修改、不受信任的操作系统中的应⽤程序提供安全容器。Bastion的管理程序可确保操作系统不会⼲扰安全容器。Intel的VMX是Bastion对使⽤嵌套页表的体系结构的虚拟化扩展。

系统管理程序在OS页表中强制执⾏容器的所需内存映射，每个Bastion容器都有⼀个安全段，其中列出了所有容器页⾯的虚拟地址和权限，并且管理程序维护着⼀个模块状态表，该表存储着⼀个反向页⾯映射，从⽽将每个物理内存页⾯与其容器和虚拟地址相关联。在使⽤地址转换结果更新TLB之前，将处理器的硬件页⾯漫游器进⾏修改，以在每次TLB未命中时调⽤管理程序。系统管理程序检查转换所使⽤的虚拟地址是否与与模块状态表中的物理地址相关联的预期虚拟地址匹配。

Bastion的缓存⾏未使⽤容器标识符进⾏标记，⽽是仅标记TLB条⽬，系统管理程序的TLB未命中处理程序会在创建每个TLB条⽬时为其设置容器标识符。与XOM和Aegis相似，安全处理器在每次访问内存时都会根据当前容器的标识符检查TLB标签。

Bastion提供了与Aegis⼀样的针对物理DRAM攻击的保护，⽽没有限制容器的数据必须存储在连续DRAM范围内。这可以通过使⽤启⽤内存加密和HMACing的标志扩展⾼速缓存⾏和TLB条⽬来实现。系统管理程序的TLB未命中处理程序在TLB条⽬上设置标志，并且这些标志在内存写⼊时传播到⾼速缓存⾏。

Bastion管理程序允许不受信任的操作系统逐出安全的容器页⾯，逐出的页⾯经过HMAC加密，并由系统管理程序维护的Merkle树覆盖。因此，系统管理程序可确保交换页⾯的机密性，真实性和新鲜度。但是，可以⾃由逐出容器页⾯的功能使恶意操作系统可以按页⾯粒度了解容器的内存访问。此外，堡垒的威胁模型不包括缓存定时攻击。

Bastion不信任该平台的固件，并在固件在引导过程中完成其作⽤后，计算虚拟机管理程序的加密哈希，系统管理程序的哈希包含在软件证明报告的测量中。

Intel SGX in Context

英特尔的Software Guard Extensions（SGX）为应⽤程序实现了安全容器，⽽⽆需对处理器的关键执⾏路径进⾏任何修改。SGX不信任计算机软件堆栈（固件，虚拟机管理程序，操作系统）中的任何层。相反，SGX的TCB由CPU的微代码和⼀些特权容器组成。SGX引⼊了⼀种解决⽅案，可通过共享，⼀致的末级缓存解决多核处理器提出的⼀些问题。

SGX不会使⽤容器标识位扩展缓存或TLB，并且在常规内存访问期间不需要任何安全检查，正如TrustZone⽂档中所建议的那样，SGX始终确保内核的TLB仅包含其正在执⾏的容器的条⽬，这要求在容器和不受信任的软件之间进⾏上下⽂切换时刷新CPU内核的TLB。

SGX遵循Bastion的⽅法，即让不受信任的OS管理安全容器使⽤的页表。依靠反向页⾯映射（EPCM）拒绝不属于当前容器的内存的地址转换，可以通过TLB未命中处理程序维护容器的安全性。

像Bastion⼀样，SGX允许不受信任的操作系统以受控⽅式驱逐安全容器页⾯。在操作系统启动容器页⾯驱逐之后，它必须向SGX实施证明，它还将容器从执⾏其代码的所有内核中移出，从⽽有效地执⾏了⾮常粗粒度的TLB shutdown。

SGX的微代码可确保每个容器（如Bastion的管理程序）被逐出的页⾯的机密性，真实性和新鲜度。但是，SGX依赖于受Aegis 启发的基于版本的Merkle树，并添加了创新的功能，使操作系统可以动态塑造Merkle树。SGX还共享了Bastion和Aegis的内存访问模式泄漏漏洞，即恶意操作系统可以按页⾯粒度直接了解容器的内存访问，并且任何软件都可以执⾏缓存定时攻击。

SGX的软件认证是使⽤Intel的增强型隐私ID（EPID）组签名⽅案实施的，该⽅案对于微码实施⽽⾔太复杂了。因此，SGX依赖各种特权容器，这些特权容器可以直接访问SGX处理器的硬件密钥，与TXT的SINIT ACM类似，特权容器使⽤Intel私钥进⾏签名，其私钥对应的公钥被硬编码到SGX微码中。

由于SGX不能防⽌⾼速缓存定时攻击，因此特权enclave的作者不能使⽤依赖于数据的内存访问。例如，对计算证明签名的报价区域的缓存攻击，将利⽤处理器的EPID签名密钥提供攻击，并完全损害SGX。

英特尔的⽂档指出，SGX通过内存加密引擎（MEE）保证DRAM的机密性，⾝份验证和更新。MEE在ISCA 2015教程中进⾏了⾮正式描述，并且似乎缺乏正式规范。在没有更多信息的情况下，我们假设SGX对Aegis和Bastion提供的物理DRAM攻击提供相同的保护。

Sanctum

Sanctum 引⼊了⼀种简单的软件/硬件协同设计，它具有与SGX相同的抵御软件攻击的能⼒，并增加了针对内存访问模式泄漏的保护，例如页⾯错误监视攻击和缓存定时攻击。

Sanctum使⽤概念上简单的缓存分区⽅案，该⽅案将计算机的DRAM分为相等⼤⼩的连续DRAM区域，并且每个DRAM区域在共享的末级缓存（LLC）中使⽤不同的集合，每个DRAM区域恰好分配给⼀个容器，因此容器在DRAM和LLC中都是隔离的。通过在上下⽂开关上进⾏刷新，可以将容器隔离在其他缓存中。

像XOM，Aegis和Bastion⼀样，Sanctum还认为虚拟机管理程序，OS和应⽤程序软件在概念上属于⼀个单独的容器，通过使容器彼此隔离的相同措施，可以保护容器免受不受信任的外部软件的侵害。

Sanctum依赖于受信任的安全监视器，该监视器是处理器执⾏的第⼀部分固件，并且具有与Aegis安全内核相同的安全属性。该监视器通过处理器ROM中的引导程序代码进⾏度量，并且其加密哈希包含在软件证明度量中。监视器验证操作系统的资源分配决策，例如，它确保两个不同的容器都⽆法访问DRAM区域。

每个Sanctum容器管理映射其DRAM区域的⾃⼰的页表，并处理⾃⼰的页错误，因此，恶意操作系统⽆法学习会导致容器中出现页⾯错误的虚拟地址。Sanctum的硬件修改与安全监视器配合使⽤，以确保容器的页表仅引⽤容器DRAM区域内的内存。

Sanctum的设计完全专注于软件攻击，不能提供任何物理攻击的保护。作者希望Sanctum的硬件修改能够与Aegis或Ascend中的物理攻击保护结合在⼀起。

Ascend and Phantom

Ascend和Phantom安全处理器在CPU的内存控制器中引⼊了Oblivious RAM 技术的实际实现，这些处理器可以抵抗攻击者的攻击，他们可以探测DRAM地址总线并尝试从其DRAM存储器访问模式中学习容器的私有信息。

在存储器控制器中实现ORAM⽅案在很⼤程度上与上述其他安全体系结构相关。例如，可以将Ascend的ORAM实现与Aegis的内存加密和⾝份验证以及Sanctum的硬件扩展和安全监控器相结合，从⽽⽣产出可以抵御软件攻击和物理DRAM攻击的安全处理器。