Intel SGX Threading and vs TCS

Question

I am trying to understand the difference between the SGX threads enabled by TCS and the untrusted thread provided by the SDK .

If I understand correctly, TCS allows multiple logical processors to enter the same enclave. Each logical processor will have its own TCS and, therefore, its own entry point ( OENTRY field in TCS). Each thread runs until AEX occurs or reaches the end of the thread. However, these streams enabled by TCS cannot synchronize with each other. At least for synchronization there is no SGX instruction.

Then, on the other hand, the SGX SDK offers a set of theme synchronization primitives , mainly a mutex and a condition variable. These primitives do not trust, as they are ultimately served by the OS.

My question is, are these Sync Primitives topics that TCS threads should use? If so, would this not compromise security? The OS can play with the schedule at its discretion.

Answer 1

First , let's take a look at your somewhat fuzzy terminology

SGX streams allowed by TCS and untrusted streaming provided by the SDK.

Inside the enclave, only trusted threads can run. There is no “unreliable" thread in the enclave. Perhaps the following sentence in the SDK Guide [1] misled you:

Threading inside an enclave is not supported. Themes that work inside the enclave are created inside the (untrustworthy) application.

An invalid application must configure the TCS pages (for more details on TCS, see [2]). So how does a TCS created by an untrusted application become the foundation for reliable flows inside an enclave? [2] gives the answer:

EENTER is only guaranteed to make controlled transitions within the enclave code if the contents of all TCS pages are measured.

By measuring TCS pages, thread integrity (TCS determines acceptable entry points) can be verified by attesting the enclave. Thus, in the enclave, only well-known good paths can be executed.

Second , look at the synchronization primitives.

The SDK offers synchronization primitives that you say are not trustworthy because they are ultimately served by the OS. Let's look at the description of these primitives in [1]:

• sgx_spin_lock () , and unlocking works only inside the enclave (using atomic operations), without the need to interact with the OS (without OCALL). Using spin lock, you yourself can implement higher-level primitives.
• sgx_thread_mutex_init () also does not do OCALL. The mutex data structure is initialized inside the enclave.
• sgx_thread_mutex_lock () and unlock, possibly execute OCALLS. However, since the mutex data is inside the enclave, it can always ensure that it is locked correctly in the protected enclave.

Looking at the descriptions of the functions of the mutex, I assume that OCALL are used to perform unoccupied, waiting outside the enclave. This is really handled by the OS and is prone to attacks. The OS may choose not to wake a thread waiting outside the enclave. But it can also interrupt the flow running inside the enclave. SGX does not protect against DoS attacks (denial of service) from a (potentially compromised) OS.

To summarize , spin locks (and, as a result, any higher-level synchronization) can be reliably implemented inside the enclave. However, SGX does not protect against DoS attacks, and therefore you cannot assume that the thread will be started. This also applies to fixing primitives: a thread waiting for a mutex cannot be woken up when the mutex is released. Realizing this inherent limitation, the SDK developers decided to use (unreliable) OCALL to effectively implement some synchronization primitives (i.e. Not busy with expectations).

[1] SGX SDK Guide

[2] SGX Explained

Answer 2

qweruiop, regarding your question in a comment (my answer is too long for a comment):

I would still consider this a DoS attack: the OS, which manages enclave resources, denies T access to CPU resource processing time. But I agree, you need to develop other threads running in this enclave, with the knowledge that T will never work. Semantics are different from running threads on a managed platform. If you want to be absolutely sure that the condition variable is checked, you must do this on the platform that you control.

sgx_status_t, returned by each proxy function (for example, when creating an ECALL in the enclave), can return SGX_ERROR_OUT_OF_TCS . Therefore, the SDK should process all threads for you - just make ECALL from two different ("unreliable") threads A and B outside the enclave, and the execution thread should continue in two ("trusted") threads inside the enclave, each of which is associated with a separate TCS (subject to the presence of 2 unused TCS).