search

integritee-network / worker

Integritee off-chain worker and sidechain validateer
Apache License 2.0
89 stars 46 forks source link

Update TCSPolicy in Enclave Config #753

Closed haerdib closed 2 years ago

haerdib commented 2 years ago

Our TCSPolicy in the Enclave Config <TCSPolicy>0</TCSPolicy> should be updated, as previously set to 0 as default, is now set to 1 according to Intel. If it's 0, the following holds true:

As long as the untrusted thread is alive, the TCS cannot be used for another thread. https://community.intel.com/t5/Intel-Software-Guard-Extensions/Thread-handling-in-SGX/td-p/1292867

That does not seem necessary and might cause TCS problems in the future.

Thanks to @Kailai-Wang for pointing this out.

haerdib commented 2 years ago

We can currently not switch to the unbound TCS policy, because futures::executor::block_on() actively uses the TLS (thread local storage).

If we get rid of the block_on() I believe we should be able to switch: https://github.com/integritee-network/worker/blob/79aa3a8be5a4bb354ca31567c21627611b644365/sidechain/rpc-handler/src/direct_top_pool_api.rs#L145

murerfel commented 2 years ago

Is this an implementation/ futures crate specific requirement (or can there be other implementations that don't have this requirement)? Because as long as we have async/await parts in our enclave code (like the top pool for instance), we will need a way to execute a future (like futures::executor::block_on() does)

haerdib commented 2 years ago

I have not investigated further there, as it's currently not necessary to switch the TCS Policy. Additionally, the executor part of futures already seems outdated. futures-sgx has simply stalled as v3.0.8. So I think an update should come before the investigation part.

haerdib commented 2 years ago

With https://github.com/integritee-network/worker/pull/938 we are now actively using thread local storage, so we need our TCS policy to be on 0. Closing this for now.