Enclave - SGX 101
Fleeting- External reference: https://sgx101.gitbook.io/sgx101/sgx-bootstrap/enclave
Enclave - SGX 101
Non-enclave software cannot directly access the EPC, as it is contained in the PRM.
SGX was designed to minimize the effort required to convert application code to take advantage of enclaves.
Each enclave designates an area in its virtual address space, called the enclave linear address range (ELRANGE), which is used to map the code and the sensitive data stored in the enclave’s EPC pages.
enclaves must store all their code and private data inside ELRANGE, and must consider the memory outside ELRANGE to be an untrusted interface to the outside world.
enclave’s code uses the same address translation process and page tables as its host application. This minimizes the amount of changes required to add SGX support to existing system software. At the same time, having the page tables managed by untrusted system software opens SGX up to the address translation attacks.
Both ECALL and OCALL are defined by developers using Enclave Definition Language (EDL), and they together consist the enclave boundary
When the project is built, the Edger8r tool […] parses the EDL file and generates […] proxy functions. […] Each ECALL and OCALL gets a pair of proxy functions: a trusted half and an untrusted half. […] Your program does not call the ECALL and OCALL functions directly; it calls the proxy functions. When you make an ECALL, you call the untrusted proxy function for the ECALL, which in turn calls the trusted proxy function inside the enclave. That proxy then calls the “real” ECALL and the return value propagates back to the untrusted function […] When you make an OCALL, the sequence is reversed: you call the trusted proxy function for the OCALL, which calls an untrusted proxy function outside the enclave that, in turn, invokes the “real” OCALL
When creating the enclave, it looks like sgx gives us a token to save and give back later, when restarting the enclave. Also, this token might be updated and the creation of the enclave says so using the updated parameter.
/* read the token from saved file */
size_t read_num = fread(token, 1, sizeof(sgx_launch_token_t), fp);
if (read_num != 0 && read_num != sizeof(sgx_launch_token_t)) {
/* if token is invalid, clear the buffer */
memset(&token, 0x0, sizeof(sgx_launch_token_t));
printf("Warning: Invalid launch token read from \"%s\".\n", token_path);
}
sgx_create_enclave(ENCLAVE_FILENAME, SGX_DEBUG_FLAG, &token, &updated, &global_eid, NULL);
The proxy functions are responsible for:
- Marshaling data into and out of the enclave
- Placing the return value of the real ECALL or OCALL in an address referenced by a pointer parameter
- Returning the success or failure of the ECALL or OCALL itself as an sgx_status_t value
AESM management agent, which provides the abstraction to access Architectural Enclaves. AESM runs as a daemon process aesmd when the system starts.aesmd provides an untrusted API to communicate with Architectural Enclaves using a domain socket, whose path is hard-coded at /var/run/aesmd/aesm.socket
SGX stores per-enclave metadata in a SGX Enclave Control Structure (SECS)
SGX was designed to minimize the effort required to convert application code to take advantage of enclaves.
SGX design fully supports multi-core processors
area used to store an enclave thread’s execution context while a hardware exception is handled is called a State Save Area (SSA)
To initialize an enclave, four of the new CPU instructions
An enclave is born when the system software issues the ECREATE instruction
free EPC page into the SECS for the new enclave
EADD instructions to load the initial code and data into the enclave.
EEXTEND instruction, which updates the enclave’s measurement used in the software attestation process. It updates the MRENCLAVE measurement register of an SECS with the measurement of an EXTEND string composed of EEXTEND || ENCLAVEOFFSET || PADDING || 256 bytes of the enclave page
After EINIT, the MRENCLAVE measurement is complete, and the enclave is ready to start user code execution using EENTER instruction.
- ECALL: “Enclave Call”, a call made into an interface function within the enclave
- OCALL: “Out Call”, a call made from within the enclave to the outside application
- Trusted: Refers to any code or construct that runs inside an enclave in a “trusted” environment.
- Trusted Thread Context: The context for a thread running inside the enclave. This is composed of:
- Thread Control Structure (TCS)
- Thread Data/Thread Local Storage: data within the enclave and specific to the thread
- State Save Area(SSA): a data buffer which holds register state when an enclave must exit due to an interrupt or exception
- Stack: a stack located within the enclave
- Untrusted: Refers to any code or construct that runs in the applications “untrusted” environment (outside of the enclave).
This is the general approach we’ll follow for designing an application for Intel SGX:Identify the application’s secrets.Identify the providers and consumers of those secrets.Determine the enclave boundary.Tailor the application components for the enclave.
Both ECALLs and OCALLs are defined by developers using Enclave Definition Language (EDL), and they together consist the enclave boundary.
Edger8r tool that is included with the Intel SGX SDK parses the EDL file and generates a series of proxy functions
These proxy functions are essentially wrappers around the real functions that are prototyped in the EDL. Each ECALL and OCALL gets a pair of proxy functions: a trusted half and an untrusted half
Your program does not call the ECALL and OCALL functions directly; it calls the proxy functions
