Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Sam5
New Contributor I
375 Views

Intel SGX Threading and vs TCS

Jump to solution

Hi,

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.

-Thanks

0 Kudos
1 Solution
375 Views

Hi Sam,

Inside an enclave, only "trusted" threads can execute. There is no "untrusted" threading inside an enclave. 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. 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.

The SDK does offer synchronization primitives, which you say are not to be trusted because they are eventually served by the OS. 

  • 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.

Thanks and Reagrds,
Surenthar Selvaraj

View solution in original post

3 Replies
376 Views

Hi Sam,

Inside an enclave, only "trusted" threads can execute. There is no "untrusted" threading inside an enclave. 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. 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.

The SDK does offer synchronization primitives, which you say are not to be trusted because they are eventually served by the OS. 

  • 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.

Thanks and Reagrds,
Surenthar Selvaraj

View solution in original post

Sam5
New Contributor I
375 Views

Thanks for your detailed Information Surenthar....

Juan_d_Intel
Employee
375 Views

Surenthar, your are spot on. OCALLS only serve to implement non-busy waiting outside the enclave.

If a thread is woken up incorrectly before the mutex/condition variable logic dictates it so, that thread will make another OCALL to get suspended again. On the other hand, holding up a thread that was supposed to have been woken up (DoS attack) won't compromise the enclave security properties either.

Reply