The Intel Software Guard Extensions software stack supports standard defense-in depth mechanisms such as stack probing, buffer overflow protection and, on Windows OS, safe structured exception handling. Enclave writers should set the compiler options such that by default enclaves are built with standard defense in-depth mechanisms available on a given platform. Regarding stack buffer overflow protection, developers must be aware that the commonly used compiler options only provide protection when the buffer meets certain criteria. For instance, Microsoft* Visual Studio compiler option
/GSand GNU* compiler option
–fstack-protectordo not provide protection when the size of the buffer in stack is below certain threshold to avoid significant performance penalty. The enclave writer must evaluate whether this security check should be enabled in enclave functions that would remain unprotected otherwise (enclave interface functions, for instance) and apply more strict checking options, such as Visual Studio compiler option
/sdland GNU compiler options
–fstack-protector-explicit, to specific modules. Note that the Intel(R) Compiler for Windows* does support option
/GSbut does not support
/sdl. Similary, the Intel(R) Compiler for Linux* supports
–fstack-protector-allbut does not support
–fstack-protector-explicit. GNU compiler supports options
–fstack-protector-explicitin version 4.9.2. Address Space Layout Randomization (ASLR) is not supported within an enclave. However, the randomization of the load address of the enclave is dependent on the operating system. Different versions of Windows* may randomize (or not randomize) the location differently. A compromised loader or OS (both of which are outside the TCB) can remove the randomization entirely. The enclave writer should not rely on the randomization of the base address of the enclave.
The ideal enclave would also have a defense-in-depth mechanism that ensured that all sections containing executable code would also be non-writable. This would protect the enclave from an attack that managed to inject code into the enclave and then execute it. However, the nature of how an enclave is loaded impacts the ability of the enclave to ensure that all code pages are non-writable. The main point is that the image of the enclave must be loaded into the EPC before it can be relocated. Since relocations need to be performed after the EPC is loaded, any code pages containing relocations have to be loaded with write permission. This opens the door for the attack mentioned above. The best option to protect against this potential attack is for the code to contain no relocations. This can be done differently depending on the format of the linked image and whether it is a 32- or 64-bit enclave. The trusted libraries that are either part of the SGX support software or provided by a 3rd party should not contain any text relocations. In addition, the tool provided to ISVs for signing their enclaves should output a warning if an enclave image contains any relocation in the .text sections, which means the final enclave will have writable code pages.