Build SGX-SDK with Clang

[Shachee Mishra]

Hi,

I have been trying to build sgx-sdk from here using clang. I can not find any resources on how to build or if it is even possible to build using clang. 

I just needed to know if there any specific reasons for not supporting clang or if we can expect a release in the future. 

I have been trying to build it using clang, but keep running into language-specific issues like implicit function declaration etc. 

Thanks, 

[Dionna (Asylo Team)]

Hi Shachee, thanks for the question. Intel does not support building SGX SDK with Clang. I can tell you a little bit from my experience in attempting to add clang support to Asylo, since that may help shape your understanding of the difficulties that may be encountered adding clang support to sgx-sdk.

Asylo uses only a small subset of SGX SDK to create enclave contexts to launch. Because Asylo only shares a small amount of SGX SDK code and uses a different build method, clang support for Asylo would not immediately translate to clang support for SGX SDK.

The issues I encountered are a bit esoteric, but here’s what I learned as I traversed this rabbit hole, in case it’s at all helpful:

Clang introduces more unsupported (by Asylo) system calls in generated code than GCC, imposes more compiler flags in the Linux x86-64 compiler triple that our Bazel crosstool simply cannot override, and generally has a very difficult time with the combination of flags “-static”, “-shared”, and “-fPIE”, which we’ve been using to build enclaves with SGX SDK. The shared object requirement is checked in the SGX SDK ELF loader, and disabling the check didn’t help me. Using any existing compiler triple I think is just not possible with the compilation requirements and the libc that Asylo uses (mprotect for example is not supported), so I experimented with a new triple specifically for SGX, newlib, and the gnu ABI. I couldn’t get the static PIE and shared object requirements to work correctly in clang.

There are further difficulties with compiling Asylo’s C++ implementation within clang, regardless of backend technology, because of libc++ (instead of GCC’s libstdc++). I think the implicit function declaration you’re hitting is most likely from the lack of long double maths support in newlib, which libc++ requires in order to build. I worked around this issue by linking musl libc’s math implementations into our newlib-based libm, but it wasn’t enough to support a clang-based toolchain. I do think Asylo will need to move entirely to musl before a clang-based toolchain will be possible.

Apart from that, the confidential computing consortium’s OpenEnclave library is intended as a substitute SDK for SGX development that natively builds on clang, uses musl-libc, and treats enclave binaries as executables (doesn’t use -shared). If you have a strong need for clang and sgx-sdk together, I recommend reaching out to Intel with a github issue.

Regards,

Dionna (Asylo Team)

[shmishra]

Hi Dionna, 

Sorry for my delayed response. 

Thankyou for addressing my issue and for such a detailed description. 

I understood most of your concerns and most of the issues I was encountering were related to compile time flags and GCC functionalities not available in clang. 

Ultimately I was able to build sgx-sdk using clang. It was not the most optimized because a number of compiler flags had to be omitted, but still it built. 

But even the simplest test programs in SIM mode are faulting at illegal instruction traps on the CPU. 

Thanks for the suggestion about OpenEnclave, I will look into it.