Intel(R) Software Guard Extensions (Intel(R) SGX) software, including an Intel(R) SGX run time system, can be developed using standard tools and development environments. While the programming paradigm is very similar to non-SGX software, there are some differences in how the Intel(R) SGX software is designed, developed and debugged to take advantage of the Intel SGX technology.
In this section, we compare the programming model available for developing enclaves and the programming model Independent Software Vendors (ISVs) are familiar with as the result of developing traditional applications for Android*, Linux*, OS X*, and Windows* operating systems. There are certain similarities that lower the barrier of entry to developers willing to adopt the Intel SGX technology. However, enclave writers must also be aware of the differences in how SGX software is designed, developed and debugged to create robust enclaves. Features unique to Intel SGX such as attestation, provisioning and sealing are described in other sections of this document.
Enclave writers that understand the technology as well as the programming model it entails will extract the most benefit from Intel SGX. Developers must observe the following principles to develop application enclaves correctly. Failing to do so could result in a security vulnerability that could be exploited later on.
An enclave is a monolithic software entity that reduces the Trusted Computing Base (TCB) for an application to a trusted runtime system, ISV code and 3rd party trusted libraries. A bug in one component may compromise the security properties of the enclave.
The untrusted domain controls the order in which the enclave interface functions are invoked.
When calling into an enclave, it is the untrusted domain who selects the Trusted Thread Context to be used within the enclave.
There is no guarantee that the input parameters of a call into an enclave (ECall) or the return parameters from a call outside an enclave (OCall) will be what the enclave expects because the untrusted domain supplies them.
The untrusted function invoked during an OCall may not perform the operations expected by the enclave.
Anyone may load an enclave. Furthermore, an attacker may load an enclave with a program specifically developed to expose vulnerabilities in that enclave.