英特尔SGX线程和vs TCS

Question

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

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

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

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

Answer 1

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

  

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

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

  

飞地内部创建的线程不被支持。该飞地内运行线程的（不可信）应用程序中创建的。

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

  

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

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

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

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

• sgx_spin_lock（）并且解锁仅在飞地内运行（使用原子操作），无需OS交互（无OCALL）。使用自旋锁，您可以自己实现更高级的原语。
• sgx_thread_mutex_init（）也不会成为OCALL。互斥数据结构在安全区内初始化。
• sgx_thread_mutex_lock（）并解锁可能执行的OCALLS。但是，由于互斥数据位于安全区内，因此它们始终可以在安全区内强制执行锁定。

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

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

[1] SGX SDK Guide

[2] SGX Explained

Answer 2

qweruiop，关于你在评论中提出的问题（我的回答太长，无法发表评论）：

我仍然认为这是一次DoS攻击：管理飞地资源的操作系统拒绝T访问资源 CPU处理时间。 但我同意，你必须设计在该飞地中运行的其他线程，并意识到T可能永远不会运行。语义与在您控制的平台上运行线程不同。如果您想确保选中条件变量，则必须在您控制的平台上执行此操作。

每个代理函数返回的sgx_status_t（例如，当ECALL进入安全区时）可以返回SGX_ERROR_OUT_OF_TCS。所以SDK应该为你处理所有线程 - 只需从安全区外的两个不同（“不可信”）线程A和B进行ECALL，并且执行流应该在包围区内的两个（“可信”）线程中继续，每个线程都绑定到一个单独的TCS（假设有2个未使用的TCS可用）。