Intel® Software Guard Extensions (Intel® SGX)
Use hardware-based isolation and memory encryption to provide more code protection in your solutions.
1310 Discussions

Intel(R) Software Guard Extensions SDK 1.9 Version for Linux OS* now available


The Intel(R) SGX SDK 1.9 Version for Linux* OS Open Source project is now live and can be found here:

The code is hosted here: (link is external) and (link is external)

- Surenthar

0 Kudos
4 Replies

Thanks for the hard work!


Hi everyone!

We are currently using Version 1.9 from your homepage.

1. At the moment we use clang for compiling. There seems to be an issue with the version of libcxx which came with the sgxsdk. Even compiling Cxx11SGXDemo with CC=clang and CXX=clang++ does not work for us. The resulting error was:

    In file included from Enclave/TrustedLibrary/Libcxx.cpp:32:
In file included from /opt/intel/sgxsdk/include/libcxx/string:437:
/opt/intel/sgxsdk/include/libcxx/__config:424:11: fatal error: 'features.h' file not found
# include <features.h>

At the other hand compiling with gcc works fine.

2. There seems to be still no sgx_enable_device()-function in the Linux libraries. (Version

3. You wrote in your license agreement for SGX that we are responsible for distribution of the PSW. Is it mandatory to keep the same form you provide it (binary executable installer), or can we "repackage" it in another package format (Debian-Package)?

4. In your Document "Intel Software Guard Extentsions SDK for Linux OS" at page 114 you mention a static version of the "Untrusted Run-Time System" library. (libsgx_urts.a).  Where can we find these? We have installed SGXSDK and PSW but it’s not there. We need it, because as soon as we link the untrusted files from edger8r to our app (just like your examples do) there are some unresolved symbols (i.E. sgx_thread_wait_untrusted_event_ocall). It seems that these symbols are defined in libsgx_urts.a.


Hello, Experts!

I am a newbie of SGX. I am wondering that if I can extract the SGX specified instructions in the initial content of target plaintext within a compromised OS kernel and reassemble a new file with the same control flow except for the extracted SGX instructions (i.e. EADD, EINIT,etc.)  then invoke the interfaces. As a result, both application and the file are running outside the enclave. And I can get the same result as inside the enclave since I have the same input and processing code. 

Is it possible or are there any problems that I did not take into consideration? Is it under the threat model of SGX?


This forum is dead...