SGX

是一种 TEE 的实现。SGX 不同于之前的 TEE 实现，比如 ARM 的 TrustZone。SGX 每个 APP 都可以有自己独立的 TEE，甚至可以创建多个 TEE；而 TrustZone 是整个系统只有一个 TEE。因此 SGX 也省去了向设备厂商申请将 TA （可信应用）装入 TEE 的过程。由于 SGX 的先进性，目前云端机密计算领域甚至已公认用 Enclave 这个词来指代 TEE。

加载到 enclave 中去的代码和数据必须被度量.当应用程序需要保护的部分加载到 enclave 后, SGX 保护它们不被外部软件所访问。

巨头争相布局的“机密计算”，究竟机密在哪？ - 知乎

(39 封私信 / 54 条消息) Intel SGX技术详细解释（非常棒） - 知乎

SGX 在 SDM 中的位置 / SGX Spec

SGX 威胁模型 & SGX TCB

  • 防其他的 Ring 3 Userspace 软件；
  • 防 Ring 0 的 kernel space 软件；也就是说内核不属于 TCB。
  • Boot code attacker。

SGX TCB 包含哪些？

  • Provisioning & Quoting Enclave
  • 硬件签名的微码 Microcode（和 TDX Module 的作用比较像？）

General overview of Intel SGX

SGX 能防御哪些攻击？

为代码和数据提供机密性和完整性，主要为了防范内核攻击。

SGX 有没有引入类似于 TDX SEAM Mode 的新硬件运行模式？

  • Kernel Enclave Mode: Invalid 的 ❌；
  • Userspace Enclave Mode: 运行在 Enclave 中的用户软件；
  • Kernel non-enclave mode: Kernel；
  • Userspace non-enclave mode: 运行在同一平台上的其他普通用户态软件。

有 Enclave mode。对于使用 MOV 等指令访问 enclave 内部的页面的情况，硬件将执行下列的检查：

  • 处理器当前运行在 enclave mode 中;
  • 访问地址在 enclave 地址空间;
  • 物理地址在 EPC 内存中;
  • EPCM(enclave page cache map) 检查，请求访问的页属于正在运行的 enclave。

内核要 load 一个应用程序，那么只需要在调度侧把应用程序当前的 EIP 放在寄存器中，

EENTER, ERESUME, EEXIT。

  • 不受信任的应用程序代码调用 EENTER 叶子函数，将控制权传递给保护区域内的代码。
  • 硬件将控制转移到保护区域内部的软件。
  • 保护区域内的软件将堆栈指针切换到保护区域内的堆栈上，使得执行过程在保护区域内进行。
  • 在保护区域内部执行相应的代码和操作。
  • 当需要从保护区域返回时，软件将堆栈指针切换回原始的堆栈，然后执行 EEXIT 叶子函数。
  • EEXIT 叶子函数将控制权返回给调用者，不受信任的应用程序代码继续执行。

KVM 要调用 Intel TDX Module，那么需要 SEAMCALL。

所有的 Enclave 操作只能在用户空间执行。

Enclave

允许用户态及内核态代码定义将特定内存区域，设置为私有区域，此区域也被称作飞地（Enclaves）。其内容受到保护，不能被本身以外的任何进程存取，包括以更高权限级别运行的进程。

威胁模型：Enclaves 是可信的，但 Enclaves 之外的任何进程都不可信（包括操作系统本身和任何虚拟化管理程序）。

Quoting Enclave

A quoting enclave is an enclave that produces quotes, or remote attestations, on behalf of enclaves running on the same machine.

SGX remote attestation

When an application receives an attestation request from an off-platform challenger

  • The application requests that its enclave produce an attestation.
  • A two-part process follows involving the application sending a local attestation from its enclave to a Quoting Enclave (QE).
  • The Quoting Enclave verifies the local-attestation and converts it into a remote attestation (a Quote) by signing the it using its asymmetric attestation key. The Quote is returned to the application and then to the challenger.
  • Finally, the Challenger can use an Attestation Verification Service to perform Quote verification.

Only a attestation is converted to a Quote can it be attested off-platform.

Ref: Supporting Third Party Attestation for Intel® SGX with Intel® Data Center Attestation Primitives

SGX vs. TDX

Fact: Intel has deprecated SGX in the 11th and 12th generations of Core processors.

Q1: Was SGX completely deprecated by Intel? A1: Not really. Only personal computer processors.

TDX 优势：

  • 基于虚拟机，所以应用天然不需要更改；
  • TDX 性能比 SGX 好，可能因为有半虚拟化、SRIOV 和 TDXIO？
  • 更安全：TCB in SGX is supposed to be smaller than in TDX；
  • SGX 不能动态更改页属性，但是 TDX 可以在 private 和 shared 之间转换。

TDX remote attestation 仍然还是用 SGX 那一套的。

Awesome-SGX-Open-Source/SGX-vs-TDX.md at master · Maxul/Awesome-SGX-Open-Source

TME-MK / TME

TME 和 TME-MK 的安全性依赖于特权软件（OS 和 VMM/Hypervisor），这点与传统虚拟化技术的安全边界完全一致。也就是 OS/VMM/Hypervisor 需要被纳入到 TCB 当中。

TME

Total Memory Encryption (TME) – the capability to encrypt the entirety of physical memory of a system. This capability is typically enabled in the very early stages of the boot process with a small change to BIOS and once configured and locked, will encrypt all the data on external memory buses of an SoC. The encryption key used for TME uses a hardware random number generator implemented in the Intel SoC, and the keys are not accessible by software or using external interfaces to the Intel SoC.

The AES XTS encryption engine is in the direct data path to external memory buses and therefore, all the memory data entering and/or leaving the SoC on memory buses is encrypted using AES XTS. The data inside the SoC (in caches, etc.) remains plain text.

NVRAM: TME 中引入的 AES-XTS 加解密引擎在不同的 RAM 情况下可以有不同配置：

  • 如果是正常内存，断电后会消失，那么就是仅仅正常的加解密；
  • 如果是非易失性内存，断电后不会消失，那么需要配置一下让 AES-XTS 在下次重启时硬件生成的 key 保持不变，不然上次加密的内容，这次就没有办法再解密了。

TME 适用性范围

可以在 OS 中，也可以在 Virtualization 中使用。

TME-MK

Motivation:

  • MKTME allows page-granular encryption of memory.
  • Can be used under virtualization environment, each VM can has its own key.

TME-MK 历史

AMD’s Secure Memory Encryption (SME) encrypted memory with a single key stored in hardware in order to protect data against physical attacks (third-party gaining unauthorized data to stolen laptops). Meanwhile, AMD’s Secure Encrypted Virtualization (SEV) offered a single encryption key per virtual machine, thus protecting a virtual machine's contents against malicious hypervisors - a feature that should be welcome in most data centers.

At the time, Intel already had its Software Guard eXtensions (SGX) feature in both enterprise and consumer chips, which acted as a “secure enclave” within a memory section for small amounts of data such as encryption keys. However, SGX can’t encrypt a whole VM or the whole memory.

Following AMD’s release of SME and SEV, Intel has also been working on Total Memory Encryption (TME) and more recently on MKTME, both of which promise to encrypt system memory at rest, at runtime, and in transit.

Intel Follows AMD's Lead on Full Memory Encryption | Tom's Hardware

TME-MK 适用性范围

TME-MK 可以在非 Virtualization 环境中使用：

[!PDF|annotate] [[MKTME.pdf#page=10&selection=7,83,9,78&color=annotate|MKTME, p.10]] The right side of the figure shows the use of TME-MK in a virtualized environment, though architecture supports use of TME-MK in a native OS deployment scenario as well.

事实上，MKTME 可以在三种环境下使用：

  • 既可以在普通环境中以 OS 来分配 KeyID，
  • 也可以和虚拟化结合让 VMM 来分配 keyID，
  • 当然也可以和 TDX 结合。

VMM (without TDX) 使用 MKTME 的示例：

![[TDX Base.pdf#page=20&rect=77,297,517,627&color=annotate TDX Base, p.20]]

TME-MK 作用机制

![[MKTME.pdf#page=9&rect=124,82,513,508&color=annotate MKTME, p.9]]
  • Hypervisor 使用 KeyID 0（即 TME 定义的平台密钥）来访问所有的加密内存。
  • VM1 和 VM2 都可以使用 KeyID 0 来访问自己的加密内存。
  • VM1 使用 KeyID 1 来访问自己的私有加密内存。
  • VM2 使用 KeyID 2 来访问自己的私有加密内存。
  • VM1 和 VM2 可以使用 KeyID 3 来访问两个 VM 共享的加密内存。

实际上，VM 是不知道自己用了哪个 KeyID 的，必须要信任 VMM 其配置是正确的。

The KeyID is included in the PTE as upper bits of the physical address field. 注意这里的 physical address 指的是 HPA 而不是 GPA，也就是 TD 里面的 Guest CR3 页表映射到的 GPA 的值还是没有变的（TME 虚拟化的情况另说）：

  • 在非虚拟化场景下，这个 keyID 是用了 physical address 的几位，这个是毋庸置疑的；
  • 在虚拟化场景下，我们有 guest CR3 页表，也有 EPT 页表，如果我们要虚拟化 MKTME 这个 feature，那么需要 guest CR3 页表的 physical address 的几位放置 keyID，如果没有开启 MKTME 虚拟化，这些 keyID 应该是用了 EPT 所映射的 HPA 的几位。MKTME 这个 feature 支持虚拟化。

MKTME 不会影响 Guest 中的 IA paging（就是 guest 走自己的页表），因为 Guest 中的 IA paging 用于产生 GPA，而不是最终的 HPA，所以设计上没必要在 Guest 的 IA paging 中设置 KeyID 字段，即 GPA 中不包含 KeyID，因此也无法为 VM 的应用再提供更细粒度的密码学隔离。MKTME 会影响 EPT paging（含每一级页表），因为 EPT 用于将 GPA 映射到 HPA，而 HPA 必须要包含 KeyID。

Intel TME和MKTME技术解析-阿里云开发者社区

MKTME requires TME and therefore cannot be enabled without enabling TME，MKTME 相比于 TME：

  • TME 对全部内存加密，MKTME 可以进行页级细粒度控制；
  • MKTME 支持多把密钥，TME 仅仅支持一把密钥。

IA32_TME_CAPABILITY [35:32] (MK_TME_MAX_KEYID_BITS), Number of bits which can be allocated for usage as key identifiers. 4 bits allow for a max value of 15, which can address 32K keys.

When MKTME is activated, the upper bits of the physical address are repurposed for usage as a KeyID.

The MKTME engine maintains an internal key table not accessible by software to store the information (key and encryption mode) associated with each KeyID. Each KeyID may be associated with three encryption modes: KeyID -> (mode, key value)。

The KeyID is an integral part of the physical address, meaning it is not only present in page tables but is also present in the TLB, caches, etc.

PCONFIG

如何保证这一切都是 host OS/VMM 来保证？Ring 0 指令 PCONFIG 用来对每一个 key 进行配置。

怎么保证 VM 不会串用别的 VM 的 keyID？

因为翻译为 HPA 这一步是 EPT 负责的，一个 VM 没有办法去改另一个 VM 的 EPT 映射所对应的 PA。因此如果 VMM 没有恶意，其有办法让 VM 之间做到隔离性。

在 TDX 的场景中，TDX Module 位于 TCB 内，且 SEPT 是由它管理的，所以 TDX Module 不会私自修改 SEPT 来让一个 TD 能够访问另一个 TD 的内存信息。

TME-MK with TDX

TME-MK Key Space Splitting

怎么保证 VMM 不会故意配置两个 TD 使用相同的 KeyID？

都是 Intel TDX Module 保证的，KVM 只能调用 SEAMCALL TDH.MNG.KEY.CONFIG 来配置。但是无法控制某一个 TD 使用哪一个 key，这些都由 Intel TDX Module 强保证。

怎么保证 VMM 不会使用 VM 的 KeyID 来访问其私有内存？

核心点在于，private HKID 在硬件设计上只能在 SEAM Mode 下访问内存，因此 KVM/QEMU 无法窃取 KeyID 来做（没有运行在 SEAM Mode），而 Intel TDX Module 虽然运行在 SEAM Mode，但是其在 TCB 内，不会这么做。

如果 VMM 是恶意的，映射自己的虚拟地址为 VM 物理地址并且使用同样的 keyID，怎么办。

如果仅仅使用 MKTME，相当于将 VMM 纳入到了 TCB 里，默认 VMM 其是善意的。 The OS/VMM can access guest memory by setting the guest KeyID bits in its paging structure entries (IA-PT).

VMM 的这种攻击被称为 KeyID caching，并且 TDX 是考虑到并做了防护的：

Intel TDX helps mitigate …. This is achieved in part by preventing the VMM from using KeyIDs that are reserved for use by TDs, helping ensure the VMM cannot directly generate requests to TD private memory with TD private KeyIDs.

The Intel TDX architecture partitions KeyIDs between Shared (VMM) and Private (TDX) usage in order to prevent the VMM from directly accessing TD private memory. Specifically, a VMM is prohibited from generating requests with Intel TDX KeyIDs and therefore can’t read/write TD private memory successfully.

技术上，TDX 引入了两块内存，shared memory 和 private memory。With TDX, the KeyID range is split into shared and private. Using private KeyIDs is restricted to the new SEAM CPU mode（也就是说只有 SEAM root mode (TDX Module) 和 SEAM non-root mode (Guest TD) 能够使用 private 的 keyID range） and thus to the TDX module and TDs. 这样，KVM/QEMU 就没有办法使用 private memory 了。这其实是 TDX 对 MKTME 做了改造。所以 legacy MKTME 和 TDX 使用了两块不同的 HKID 空间。

![[TDX Base.pdf#page=53&rect=49,118,545,488&color=annotate TDX Base, p.53]]

官方文档有只用 MKTME 不用 TDX 的 case，同时也不需要 bounce buffer，只需要保证 vt-d 页表和 EPT 页表对于同一个 GPA 映射到的 HPA 上设置的 keyID 是相同的就行，因为其实没有私有页的概念：

For legacy Intel VMX-based VMs where the VMM needs to be included in their TCB, the MKTME technology can be used to enable memory encryption and enhance it by adding support for cryptographic-integrity protection. For directed I/O use cases, the VMM needs to set a KeyID1 as part of the physical addresses in the VT-d paging structures corresponding to the KeyID as part of the physical addresses in EPT employed for the CPU side. This will allow DMAs to be able to access memory without requiring changes to I/O devices and/or I/O drivers in the legacy VM.

可以对比下 MKTME + Legacy VM vs. TDX 之间的 threat model 之间的区别。

SGX 当中的指令

Intel® Software Guard Extensions Programming Reference 这里的 Chapter 5.2。

分两类（每一个下面都有自己的 subleaf）：

  • 第一类是 ENCLS—Execute an Enclave System Function of Specified Leaf Number：
  • 第二类是 ENCLU—Execute an Enclave User Function of Specified Leaf Number

ENCLS

必须在内核模式执行。

![[SGX Programming Reference.pdf#page=59&rect=44,151,368,180&color=annotate SGX Programming Reference, p.59]]

ENCLU

必须在用户态执行。

![[SGX Programming Reference.pdf#page=61&rect=43,209,382,240&color=annotate SGX Programming Reference, p.61]]

EENTER

用户态执行。

EEXIT

ERESUME

Difference between SGX and MKTME

SGX and MKTME are both security technologies designed to protect sensitive data, but they have different use cases and approaches to achieving their goals. SGX provides secure execution environments for applications and services running on a system, while MKTME provides memory encryption for virtual machines to protect against certain types of attacks. (From ChatGPT)