英特尔SGX线程和vs TCS

Question

我试图理解由TCS启用的SGX线程与SDK提供的不受信任的线程之间的区别.

如果我理解正确,TCS允许多个逻辑处理器进入同一个飞地.每个逻辑处理器都有自己的TCS,因此也有自己的入口点(OENTRYTCS中的字段).每个线程都会运行,直到AEX发生或到达线程结束.但是,由TCS启用的这些线程无法相互同步.至少,没有用于同步的SGX指令.

然后,另一方面,SGX SDK提供了一组线程同步基元,主要是互斥和条件变量.这些原语不受信任,因为它们最终由OS提供服务.

我的问题是,这些线程同步基元是否意味着由TCS线程使用？如果是这样,这不会恶化安全吗？操作系统可以按照自己的意愿进行调度.

Answer 1

首先，让我们处理一下您有些不清楚的术语

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

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

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

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

如果测量了所有 TCS 页面的内容，则 EENTER 仅保证在飞地代码内执行受控跳转。

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

其次，让我们看看同步原语。

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

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

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

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

[1]新交所 SDK 指南

[2]新交所解释