Concurrency View

This page gives you an overview of the different processes and threads used within the Sharemind HI Server. They host the different enclaves, routine work, etc.

concurrency view
Figure 1. An overview of the processes and threads used in the Sharemind HI Server.
Enclaves

Intel® SGX allows to configure the maximum amount of threads which can be simultaneously within the enclave. Since multithreaded code is hard to get right[1], we decided to restrict this to just one thread for each enclave in the Sharemind HI Server.
Each enclave has a dedicated queue for requests to that enclave, and a thread which works through the items in that queue.

Task Enclave

Each task enclave lives in its own process. This way, an error in the task enclave won’t be able to tear down the whole Sharemind HI Server. Additionally, this allows for easier cancellation of tasks, via timeouts or through e.g. htop if a system administrator finds that a task enclave is behaving abnormally and wants to kill it.
Within the main process, the task enclave process has two additional threads, one for handling calls targeted to the task enclave, and one for calls invoked by the task enclave itself, which are targeted towards the core enclave or key enclave.
Note: Different task enclaves can run at the same time, but task enclaves themselves are single threaded. To achieve a certain amount of parallelization, you need to split the workload into ideally isolated parts and create a separate task enclave for each of them[2].

User Session Expiration

Each enclave has a thread which is responsible for cleaning up timed out user sessions (See the annotated server.yaml file, e.g. option Service::CoreEnclave::IdleTimeout).

Periodic Tasks

A couple of routine work is performed by dedicated threads:

Audit Log Output

One thread is responsible for writing audit log entries to the audit log. It receives the audit log entries from the core enclave and task enclaves through a queue.

gRPC Server

The Sharemind HI Server exposes a gRPC interface. We use the synchronous version which uses a thread pool internally.

Signal Handler

The SIGCHLD needs to be handled for cases where a task enclave process died or was killed by some outer force. This is handled by a dedicated thread.

1. https://www.ibr.cs.tu-bs.de/users/weichbr/papers/esorics2016.pdf
2. In the future we might lift this restriction.