In my previous blog post, “Intel Software Guard Extensions: When Secrets Need Extra Protection,” I gave a high-level overview of how Intel Software Guard Extensions (Intel SGX) works. In short, Intel SGX uses a combination of hardware and software to encrypt a portion of computer memory so that it is opaque to inspection, even by the computer’s OS or other programs running with elevated security privileges. This provides a means for developers to lock away sensitive data (such as encryption keys or passwords) where it cannot be accessed or manipulated by malware that might have compromised the OS.
Super security for sensitive secrets is good. But how do you actually access those secrets if they are hidden from ordinary function calls, jumps, register manipulation, or stack manipulation? The only way to call an enclave function is through a new instruction that performs several protection checks.
ECALLs and OCALLs
Applications that use Intel SGX are really split into two parts: the untrusted portion (the conventional application) and the trusted portion (in the enclave). Communication between the untrusted and trusted parts of an Intel SGX application passes solely through the call gate, the collection of Intel SGX functions that mediate information transfer to and from enclaves.
Calls going from the untrusted portion of the application into the enclave are called ECALLs. Calls from inside the enclave out to the untrusted portion of the application are called OCALLs. To get a sense of how an ECALL works, consider an ECALL in action in this generic use case shown in the following graphic:
A primary way by which ECALLs and OCALLs protect data within enclaves is by not directly passing pointers. Except in rare cases specified by the developer, ECALLs and OCALLs copy only the buffer for the memory referred to by a pointer to and from an enclave. This helps ensure that the operating system cannot see the memory address for any data used in an enclave.
Still, Intel SGX cannot protect you from yourself. For example, if you pass the secret out of the enclave and into the untrusted application, Intel SGX can’t save you. In a related fashion, enclaves should also have minimal trusted-untrusted component interaction. While enclaves can leave the protected memory region and call functions in the untrusted component (through the use of a special instruction), limiting these dependencies strengthens enclaves against attack.That covers some of the details of how Intel SGX enclaves work and communicate. In my next two installments on Intel SGX, I’ll look at what you can do with enclaves and how they maintain state.