英特尔SGX线程和vs TCS

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

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

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

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

最佳答案
首先,让我们来处理你有些不太明确的术语

SGX threads enabled by TCS and untrusted threading provided by SDK.

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

Creating threads inside the enclave is not supported. Threads that run inside the enclave are created within the (untrusted) application.

不受信任的应用程序必须设置TCS页面(有关TCS的更多背景,请参阅[2]).那么,不受信任的应用程序设置的TCS如何成为飞地内可信线程的基础? [2]给出了答案:

EENTER is only guaranteed to perform controlled jumps inside an enclave’s code if the contents of all the TCS pages are measured.

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

其次,让我们看一下同步原语.

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

> sgx_spin_lock()和unlock仅在安全区内运行(使用原子操作),无需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

转载注明原文:英特尔SGX线程和vs TCS - 代码日志