\HeadingLevelB{SGX Lightning Tour}
\label{sec:sgx_intro_tour}

SGX sets aside a memory region, called the \textit{Processor Reserved Memory}
(PRM, \S~\ref{sec:sgx_prm}). The CPU protects the PRM from all non-enclave
memory accesses, including kernel, hypervisor and SMM (\S~\ref{sec:rings})
accesses, and DMA accesses (\S~\ref{sec:motherboard}) from peripherals.

The PRM holds the \textit{Enclave Page Cache} (EPC, \S~\ref{sec:sgx_epc}),
which consists of 4~KB pages that store enclave code and data. The system
software, which is untrusted, is in charge of assigning EPC pages to enclaves.
The CPU tracks each EPC page's state in the \textit{Enclave Page Cache
Metadata} (EPCM, \S~\ref{sec:sgx_epcm}), to ensure that each EPC page belongs
to exactly one enclave.

The initial code and data in an enclave is loaded by untrusted system software.
During the loading stage (\S~\ref{sec:sgx_enclave_lifecycle}), the system
software asks the CPU to copy data from unprotected memory (outside PRM) into
EPC pages, and assigns the pages to the enclave being setup
(\S~\ref{sec:sgx_epcm}). It follows that the initial enclave state is known to
the system software.

After all of the pages belonging to the enclave are loaded into EPC, the system software asks the
CPU to mark the enclave as initialized (\S~\ref{sec:sgx_enclave_lifecycle}), 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
enclave's \textit{measurement hash} (\S~\ref{sec:sgx_measurement}).

A remote party can undergo a \textit{software attestation} process
(\S~\ref{sec:sgx_attestation}) to convince itself that it is communicating with
an enclave that has a specific measurement hash, and is running in a secure
environment.

Execution flow can only enter an enclave via special CPU instructions
(\S~\ref{sec:sgx_threads}), which are similar to the mechanism for switching
from user mode to kernel mode. Enclave execution always happens in protected
mode, at ring 3, and uses the address translation set up by the OS kernel and
hypervisor.

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 (\S~\ref{sec:sgx_aex}) 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.

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
(\S~\ref{sec:sgx_enclave_lifecycle}). 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.
