SGX2

With SGX2, Intel adapts SGX to a cloud environment by increasing the PRM from 256MB to 512GB per CPU socket. Exact sizes vary per CPU model. A major change to the SGX architecture is the release of Enclave Dynamic Memory Management (EDMM). Previously in SGX1, all of an enclave's memory had to be committed at build time with EADD and before calling EINIT. EDMM allows an enclave's memory to grow dynamically while maintaining the security guarantees of SGX. Any page added to the enclave at runtime is in a pending state and must be accepted by an enclave with the EACCEPT instruction in order to be used. This allows an enclave to validate the newly added page before using it. In addition, it is now allowed to change the access permissions stored in the EPCM of an EPC page, which is especially important for garbage collectors. SGX2 also allows threads to be spawned dynamically by adding TCSs at runtime. For the purposes of this project, it is only important to know how dynamic page allocation works. The instructions added with SGX2 can be found in the table.

EAUG	adds a page containing zeros to an initialized enclave
EMODT	modifies the page type \ \hline EMODPR & restricts access permissions of an epc page
EACCEPT	accepts a new page at runtime
EACCEPTCOPY	copies the content from an existing epc page to a newly created page by EAUG and accepts it
EMODPE	extends access permissions of an epc page

The Intel SGX driver in the kernel maintains dynamic region structures for each enclave included in the measurement. These structures define a memory region, the direction of growth (up for heap and down for stack), and an allocation alignment. The allocation alignment specifies how many pages are dynamically added to an enclave at a time. Runtime page allocation works as follows.

The enclave wants to grow a stack or heap and executes EACCEPT on it, resulting in a page fault because the page does not exist. This is done for performance reasons, as enclave entries and exits are expensive. Now, the SGX driver handles the exception, locates the dynamic region where the address that caused the page fault is, and then commits new pages until an existing page or the dynamic memory boundary or allocation alignment is reached. Since stacks and heaps grow in opposite directions, this is handled accordingly. Then the enclave retries the EACCEPT on the existing page, which will succeed. This allocation procedure is called explicit because the enclave detects it itself.

Implicit allocations occur when the enclave does not know that its issued memory access will result in a page fault. In a normal software flow, data is written to a page before it is accessed. Otherwise, there would be no data to read. So, by design, a page fault occurs on explicit allocations when a read access is made, and on implicit allocations when a write access is made. This happens because the software expects the page to already exist and tries to write data onto it. If a page fault occurs on a write access, the sgx driver handles the fault by adding new pages as described above, but now also throws an exception that includes the added pages. The exception is then handled by Gramine's pal-sgx and passed to the shielded layer. Finally, the shielded layer accepts the pages after validation.