8

I'm trying to understand the difference between SGX threads enabled by TCS and untrusted threading provided by SDK.

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

Then, on the other hand, the SGX SDK offers a set of Thread Synchronization Primitives, mainly mutex and condition variable. These primitives are not trusted since they're eventually served by OS.

My question is, are these Thread Synchronization Primitives meant to be used by TCS threads? If so, wouldn't this deteriorate the security? The OS is able to play with scheduling as it wishes.

savx2
  • 1,011
  • 2
  • 10
  • 28
qweruiop
  • 3,156
  • 6
  • 31
  • 55

2 Answers2

7

First, let us deal with your somewhat unclear terminology of

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

Inside an enclave, only "trusted" threads can execute. There is no "untrusted" threading inside an enclave. Possibly, the following sentence in the SDK Guide [1] misled you:

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

The untrusted application has to set up the TCS pages (for more background on TCS see [2]). So how can the TCS set up by the untrusted application be the foundation for trusted threads inside the enclave? [2] gives the answer:

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

By measuring the TCS pages, the integrity of the threads (the TCS defines the allowed entry points) can be verified through enclave attestation. So only known-good execution paths can be executed within the enclave.

Second, let us look at the synchronization primitives.

The SDK does offer synchronization primitives, which you say are not to be trusted because they are eventually served by the OS. Lets look at the description of these primitives in [1]:

  • sgx_spin_lock() and unlock operate solely within the enclave (using atomic operations), with no need for OS interaction (no OCALL). Using a spinlock, you could yourself implement higher-level primitives.
  • sgx_thread_mutex_init() also does not make an OCALL. The mutex data structure is initialized within the enclave.
  • sgx_thread_mutex_lock() and unlock potentially perform OCALLS. However, since the mutex data is within the enclave, they can always enforce correctness of locking within the secure enclave.

Looking at the descriptions of the mutex functions, my guess is that the OCALLs serve to implement non-busy waiting outside the enclave. This is indeed handled by the OS, and susceptible to attacks. The OS may choose not to wake a thread waiting outside the enclave. But it can also choose to interrupt a thread running inside an enclave. SGX does not protect against DoS attacks (Denial of Service) from the (potentially compromised) OS.

To summarize, spin-locks (and by extension any higher-level synchronization) can be implemented securely inside an enclave. However, SGX does not protect against DoS attacks, and therefor you cannot assume that a thread will run. This also applies to locking primitives: a thread waiting on a mutex might not be awakened when the mutex is freed. Realizing this inherent limitation, the SDK designers chose to use (untrusted) OCALLs to efficiently implement some synchronization primitives (i.e. non-busy waiting).

[1] SGX SDK Guide

[2] SGX Explained

Freddy
  • 402
  • 4
  • 8
  • Hi, Freddy. I figured later that creating multiple TCSs and EENTER to them are the only permitted threading in an enclave. So most of what you said make perfect sense. But I'm not sure if all race conditions (deliberately introduced by the OS) necessarily translate to DoS attacks. Suppose Thread T is a monitoring thread, waiting on a cond. var. and will be notified if bad things happen. Then OS can choose to never awaken T so the error will never be handled and potentially cause more damage. This example is somewhat contrived but it is possible. In this case, race condition is more than DoS. – qweruiop Mar 25 '16 at 13:18
  • By the way, do you know about the support status of threading in current SDK? For example, what API is to EENTER a TCS? – qweruiop Mar 25 '16 at 13:43
  • My answer was to long for the comment. See the other answer below. – Freddy Mar 30 '16 at 07:26
1

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

I would still count that as a DoS attack: the OS, which manages the resources of enclaves, denies T access to the resource CPU processing time. But I agree, you do have to design the other threads running in that enclave with the awareness that T might never run. The semantics are different from running threads on a platform you control. If you want to be absolutely sure that the condition variable is checked, you have to do so on a platform you control.

The sgx_status_t returned by each proxy function (e.g. when making an ECALL into an enclave) can return SGX_ERROR_OUT_OF_TCS. So the SDK should handle all threading for you - just make ECALLs from two different ("untrusted") threads A and B outside the enclave, and the execution flow should continue in two ("trusted") threads inside the enclave, each bound to a separate TCS (assuming 2 unused TCS are available).

Freddy
  • 402
  • 4
  • 8