threads 1:1 in binding mode of TCS?return SGX_ERROR_OUT_OF_TCS

[smartiov]

1.untrusted threads number must less than trusted threads in binding mode of TCS policy? if the same threads, it will not can be used for binding urts threads. 2.in is_special_ecall is false branch trust_thread = _acquire_thread(); // for edmm feature, we don't support simulation mode yet // m_utility_thread will be NULL in simulation mode if(NULL == trust_thread && NULL != m_utility_thread) { m_need_to_wait_for_new_thread_cond.lock(); m_utility_thread->get_enclave()->fill_tcs_mini_pool_fn(); m_need_to_wait_for_new_thread = true; while(m_need_to_wait_for_new_thread != false) { m_need_to_wait_for_new_thread_cond.wait(); } m_need_to_wait_for_new_thread_cond.unlock(); trust_thread = _acquire_thread(); }

[smartiov]

CTrustThread CTrustThreadPool::add_thread(tcs_t const tcs, CEnclave const enclave, bool is_unallocated) { CTrustThread trust_thread = new CTrustThread(tcs, enclave); LockGuard lock(&m_thread_mutex); //add tcs to free list if(!is_unallocated) { if (g_enclave_creator->is_EDMM_supported(enclave->get_enclave_id()) && !m_utility_thread && (enclave->get_dynamic_tcs_list_size() != 0)) m_utility_thread = trust_thread; else m_free_thread_vector.push_back(trust_thread); } else { m_unallocated_threads.push_back(trust_thread); }

return trust_thread;

} //because of the allocated the threads by m_utility_thread in SGX v2

[ghost]

The user is able to config how many TCS can be used in the configuration file. The whole architecture guarantee the application is able to use ecalls in that number of threads. The user is not aware of utility thread. The the current implementation, we have a bug in the binding mode when uRTS try to recycle TCS from the terminated threads. The bug will be fixed in the coming release.

[smartiov]

thanks 1.but my application threads is fixed, not dynamic allocated , it will not terminated threads. so ,it is not you mentioned above. 2.it is another bug in the fixed thread pool binding mode?

[ghost]

Binding means 1:1 mapping. If one thread successfully do an ecall, the TCS will never be used by another thread, until the thread terminated.

[smartiov]

thanks. that is to say , my application had ecalled the wrong threads, but each ecall function is the different thread context, iso the application threads can not call another thread tcs, whether the sdk allocated the wrong tcs to call.

[ghost]

If you are able to reproduce the issue, can you please send a test case out to help us debug it?

[smartiov]

sorry, i am a intergrated test , can not send a test case. you local testcase can not reproduce this? if you configure the 1:1, the application works normally? we can make sure the points. whether exist the wrong init node map or not , or find wrong.

[lzha101]

Could you check if you are loading your enclave in the main thread and doing ecalls in the child threads? And the TCS number is 1:1 mapping to the child thread number? If yes, it is expected to get an OUT_OF_TCS error. sgx_create_enclave() also needs to hold a TCS because it also needs to do an initialization ecall.

[smartiov]

1.good, i guess that the tcs must be occupied by some init, but i can not fix according codes. 2.my enclave init exection threads is in different from the ecall application threads.

[smartiov]

thanks the tcs used to sgx_create_enclave will be occupied normal, and not free or recycle?

[xxu36]

Hi, browsing the code and local tests cannot figure out what's going wrong in your case. So your further available information can help, such as:

1. The configurations in the enclave configuration file
2. Which driver are you using? I assume you are using driver code from https://github.com/intel/linux-sgx-driver, then which branch? master or sgx2? Thanks