The sgxsdk-2.1.2 was used

We are currently investigating a segmentation fault with the Intel SGX SDK >= 2.0. While the code runs correctly in hardware mode, the SGX SDK generates a segfault when creating the enclave.
The code runs correctly in simulation mode with the SGX SDK v1.9.

Here is an update on the problem.

In simulation mode, when the program is loaded, the dynamic loader loads the Intel SGX SDK libraries, and in particular the URTS library. This library makes function calls to the OpenSSL library when it is loaded (see sdk/simulation/urtssim/enclave_creator_sim.cpp in the Intel SGX SDK). Unfortunately, as TaLoS replaces OpenSSL these calls result in an enclave creation, which fails (and leads to the segfault) at that point because the SGX SDK has not been properly initialized yet.

The simulation mode uses some OpenSSL functions to simulate instructions of SGX. We are currently looking at ways to solve this problem. One idea would be to load both the normal OpenSSL and TaLoS and make calls to the appropriate one, depending on if the calls are issued by the SGX SDK or the application.

thanks, great!

Commit 41584e3 fixes this issue.

The SGX SDK calls the following two OpenSSL functions when its libraries are loaded: OPENSSL_add_all_algorithms_noconf() and ERR_load_crypto_strings().

Then, when the enclave is created, it calls the following functions: EVP_MD_CTX_create(), EVP_DigestInit_ex(), EVP_sha256(), EVP_DigestUpdate(), EVP_DigestFinal_ex() and EVP_MD_CTX_destroy().

In simulation mode these functions can no longer be the first ones called by your application as, until the enclave has been successfully created, they will result in a call to the system OpenSSL library instead of TaLoS.

The SGX_MODE_SIM macro, defined by the Makefile only in simulation mode, triggers this behaviour.