topic Thread handling in SGX in Intel® Software Guard Extensions (Intel® SGX)

Thread handling in SGX

Anandakumar — Thu, 24 Jun 2021 09:35:11 GMT

Hello,

This is an extension of previous thread : https://community.intel.com/t5/Intel-Software-Guard-Extensions/SGX-Threads-behavior/td-p/1290722/jump-to/first-unread-message

I need clarifications on few thread related topics,

1. Only N number of simultaneous threads can run in SGX enclave in a N core machine because each thread will be binded to a physical core.
TCS NUM( Thread Control Structure ) will decide how many threads can spawn in the SGX Enclave. Lets say M (M>N) is set as TCSNUM the N thread can run simultaneouly and the remaining M-N threads will have to wait for their schedule.

Is my understanding correct? Can we have more number of TCS than the number of cores?

2. Regarding the TCSPolicy Binded/Non-binded mode. Give me some examples that explains when to use either of them.

Thanks

Anand

Re:Thread handling in SGX

JesusG_Intel — Fri, 25 Jun 2021 00:34:01 GMT

Hello Anand,

YES. You can configure a higher TCS_NUM than the number of logical processors on a system.
TCS_POLICY causes confusion because there are 2 aspects related to it, which might not be clearly explained in our documentation.

Trusted (Enclave component):
- Unbinding policy (1): Thread Local Storage (TLS) area for each Thread Context (TCS) is reinitialized on every root ECALL.
- Binding policy (0): Thread Local Storage (TLS) is not initialized on every ECALL.
Untrusted (loader component):
- Unbinding policy (1): On every root ECALL, the uRTS finds the first available TCS and assigns said TCS to the untrusted thread.
- Binding policy (0): The uRTS binds the untrusted thread to a TCS.

As long as the untrusted thread is alive, the TCS cannot be used for another thread.

When an application creates more threads than TCSes and uses this policy you get SGX_ERROR_OUT_OF_TCS.

Binding was the default policy in the initial versions of the SGX SDK.

Then we realized that developers could run into issues with binding policy if they weren’t careful using thread synchronization functions.

For that reason, we switched the default policy to unbinding (TCS_POLICY 1).

The binding policy (TCS_NUM 0) is useful if an enclave requires preserving TLS across root ECALLs.

However, we are not aware of any use case that requires this feature.

In general, use the current default (unbinding - TCS_POLICY 1).

Sincerely,

Jesus G.

Intel Customer Support

Re:Thread handling in SGX

JesusG_Intel — Mon, 28 Jun 2021 20:57:32 GMT

This thread has been marked as answered and Intel will no longer monitor this thread. If you want a response from Intel in a follow-up question, please open a new thread.