Intel SGX线程和vs TCS

Question

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

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

另一方面，SGX提供了一组线程同步基本元素，主要是互斥变量和条件变量。这些原语是不可信的，因为它们最终由OS提供服务。

我的问题是，这些线程同步基本元素是否打算供TCS线程使用？如果是这样的话，这不会使安全问题恶化吗？操作系统能够按自己的意愿进行调度。

Answer 1

First，让我们来处理一下您对

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

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

在飞地内创造更准的线程是不支持的。在(不可信)的应用程序中创建了更高级的、更接近的、在飞地内运行的并行的线程。

不受信任的应用程序必须设置TCS页面(有关TCS的更多背景见2)。那么，由不受信任的应用程序建立的TCS如何成为飞地内可信线程的基础呢?2给出了答案：

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

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

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

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

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

查看互斥函数的描述，我的猜测是OCALLs用于实现在飞地之外的非繁忙等待。这确实是由操作系统处理的，并且容易受到攻击。操作系统可以选择不唤醒在飞地外等待的线程。但它也可以选择中断在飞地内运行的线程。SGX不保护DoS攻击(拒绝服务)免受(可能受到破坏的)操作系统的攻击。

为了总结，可以在飞地内安全地实现自旋锁(以及扩展到任何更高级别的同步)。但是，SGX并不能防止DoS攻击，因此您不能假设线程将运行。这也适用于锁定原语:等待互斥锁的线程在释放互斥对象时可能不会被唤醒。由于认识到了这个固有的限制，SDK设计人员选择使用(不受信任的) OCALLs来有效地实现一些同步原语(即非繁忙等待)。

1

2

Answer 2

qweruiop，关于你在评论中的问题(我的回答太长了，不能发表评论)：

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

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