英特尔 SGX 线程和与 TCS

Question

我试图了解 TCS 启用的 SGX 线程和 SDK 提供的不受信任的线程之间的区别。

如果我理解正确，TCS 允许多个逻辑处理器进入同一个飞地。每个逻辑处理器都有自己的 TCS，因此也有自己的入口点（TCS 中的OENTRY 字段）。每个线程运行直到 AEX 发生或到达线程的末尾。但是，这些由 TCS 启用的线程还没有办法相互同步。至少，没有用于同步的 SGX 指令。

另一方面，SGX SDK 提供了一组线程同步原语，主要是互斥体和条件变量。这些原语不受信任，因为它们最终由操作系统提供服务。

我的问题是，这些 线程同步原语 是否打算供 TCS 线程使用？如果是这样，这不会降低安全性吗？操作系统可以随心所欲地进行调度。

Answer 1

qweruiop，关于您在评论中的问题（我的回答太长，无法评论）：

我仍将其视为 DoS 攻击：管理 enclave 资源的操作系统拒绝 T 访问资源 CPU 处理时间。 但我同意，您必须设计在该飞地中运行的其他线程，并意识到 T 可能永远不会运行。语义不同于在您控制的平台上运行线程。如果你想绝对确定条件变量被检查，你必须在你控制的平台上这样做。

每个代理函数返回的 sgx_status_t（例如，将 ECALL 放入 enclave 时）可以返回 SGX_ERROR_OUT_OF_TCS。因此 SDK 应该为您处理所有线程 - 只需从飞地外的两个不同（“不可信”）线程 A 和 B 生成 ECALL，并且执行流程应该在飞地内的两个（“可信”）线程中继续，每个线程都绑定到一个单独的 TCS（假设有 2 个未使用的 TCS 可用）。

Answer 2

首先，让我们来处理一下你有点不清楚的术语

TCS 启用的 SGX 线程和 SDK 提供的不受信任的线程。

在 enclave 内，只有“受信任的”线程可以执行。飞地内没有“不受信任的”线程。可能是 SDK 指南 [1] 中的这句话误导了你：

不支持在 enclave 内创建线程。在 enclave 内运行的线程是在（不受信任的）应用程序中创建的。

不受信任的应用程序必须设置 TCS 页面（有关 TCS 的更多背景信息，请参阅 [2]）。那么不受信任的应用程序设置的 TCS 如何成为 enclave 内受信任线程的基础呢？ [2]给出了答案：

只有在测量所有 TCS 页面的内容时，EENTER 才能保证在 enclave 的代码内执行受控跳转。

通过测量 TCS 页面，可以通过 enclave 证明来验证线程的完整性（TCS 定义了允许的入口点）。因此，只有已知良好的执行路径才能在 enclave 内执行。

第二，让我们看看同步原语。

SDK 确实提供了同步原语，您说这些原语不可信，因为它们最终由操作系统提供服务。让我们看看[1]中这些原语的描述：

• sgx_spin_lock() 和解锁仅在 enclave 内操作（使用原子操作），无需操作系统交互（无 OCALL）。使用自旋锁，您可以自己实现更高级别的原语。
• sgx_thread_mutex_init() 也不会进行 OCALL。互斥锁数据结构在 enclave 内初始化。
• sgx_thread_mutex_lock() 和解锁可能会执行 OCALLS。但是，由于互斥锁数据位于 enclave 内，因此它们始终可以在安全 enclave 内强制执行锁定的正确性。

查看互斥锁函数的描述，我的猜测是 OCALL 用于在 enclave 外实现非忙等待。这确实是由操作系统处理的，并且容易受到攻击。操作系统可以选择不唤醒在飞地外等待的线程。但它也可以选择中断在飞地内运行的线程。 SGX 无法抵御来自（可能受到威胁的）操作系统的 DoS 攻击（拒绝服务）。

总而言之，自旋锁（以及任何更高级别的同步）可以安全地在 enclave 内实现。但是，SGX 不能防御 DoS 攻击，因此您不能假设线程会运行。这也适用于锁定原语：当互斥锁被释放时，等待互斥锁的线程可能不会被唤醒。意识到这一固有限制后，SDK 设计者选择使用（不受信任的）OCALL 来有效地实现一些同步原语（即非忙等待）。

[1]SGX SDK Guide

[2]SGX Explained