Intel SGX Explained
Fleeting- External reference: @cryptoeprint:2016:086
Intel SGX Explained
Annotations
the PRM’s size must be an integer power of two, and its start address must be aligned to the same power of two. Due to these restric- tions, checking if an address belongs to the PRM can be done very cheaply in hardware, using the circuit outlined
Our security analysis of SGX relies on implementation details surrounding the PRM, and will have to be re-evaluated for SGX future implementations
SGX sets aside a memory region, called the Processor Reserved Memory (PRM). The CPU protects the PRM from all non-enclave memory accesses, including kernel, hypervisor and SMM accesses, and DMA accesses from peripherals
After all the enclave’s pages are loaded into EPC, the system software asks the CPU to mark the enclave as initialized (§ 5.3), at which point application software can run the code inside the enclave. After an enclave is initialized, the loading method described above is disabled.
While an enclave is loaded, its contents is cryptographically hashed by the CPU. When the enclave is initialized, the hash is finalized, and becomes the measurement hash
the most troubling finding in our security analysis is that Intel added a launch control feature to SGX that forces each computer’s owner to gain approval from a third party (which is currently Intel) for any enclave that the owner wishes to use on the computer. […] the only publicly documented intended use for this launch control feature is a licensing mechanism that requires software developers to enter a (yet unspecified) business agreement with Intel to be able to author software that takes advantage of SGX’s protections. All the official documentation carefully sidesteps this issue, and has a minimal amount of hints that lead to the Intel’s patents on SGX. Only these patents disclose the existence of licensing plans.
The licensing issue might not bear much relevance right now, because our security analysis reveals that the limitations in SGX’s guarantees mean that a security-conscious software developer cannot in good conscience rely on SGX for secure remote computation. At the same time, should SGX ever develop better security properties, the licensing scheme described above becomes a major problem, given Intel’s near-monopoly market share of desktop and server CPUs. Specifically, the licensing limitations effectively give Intel the power to choose winners and losers in industries that rely on cloud computing.
To avoid leaking private data, a CPU that is executing enclave code does not directly service an interrupt, fault (e.g., a page fault) or VM exit. Instead, the CPU first performs an Asynchronous Enclave Exit to switch from enclave code to ring 3 code, and then services the interrupt, fault, or VM exit. The CPU performs an AEX by saving the CPU state into a predefined area inside the enclave and transfers control to a pre-specified instruction outside the enclave, replacing CPU registers with synthetic values.
This means that the contexts switch are quite costly. No wonder why the documentation recommends to avoid using them as much as possible.
The allocation of EPC pages to enclaves is delegated to the OS kernel (or hypervisor). The OS communicates its allocation decisions to the SGX implementation via special ring 0 CPU instructions. The OS can also evict EPC pages into untrusted DRAM and later load them back, using dedicated CPU instructions. SGX uses cryptographic protections to assure the confidentiality, integrity and freshness of the evicted EPC pages while they are stored in untrusted memory.