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

While this manuscript seeks to educate the reader of the challenges, history, and state of the art in secure processors for remote computation, this discussion is grounded in the example of Intel's Software Guard Extensions (SGX), as it is an available, documented, and modern system that aims to offer useful security guarantees to remotely executed programs. This section presents a brief overview of the SGX platform, directing the reader to other sections of the manuscript for a deeper look at each aspect of SGX.

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 management engine (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 is assigned exclusively, belonging to exactly one enclave.

The initial code and data in an enclave is loaded by untrusted system software.
During loading (\S~\ref{sec:sgx_enclave_lifecycle}), 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 the enclave's pages 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 may execute code inside the enclave. After an
enclave is initialized, the loading mechanism briefly described above is no longer available to system software.

While an enclave is loaded, its contents and configuration are cryptographically hashed by the
CPU. When the enclave is initialized, this hash is finalized, and becomes the
enclave's \textit{measurement hash} (\S~\ref{sec:sgx_measurement}).

A remote party can communicate with the enclave to perform \textit{software attestation} (\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}), similar to the mode switching mechanism for transitioning between user and kernel modes of execution in a typical system. An enclave must execute in protected mode, at ring 3, and uses virtual address translation as set up by the OS kernel and hypervisor.

To avoid leaking private information, a CPU executing enclave code does not
directly service any 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 given scrubbed fault information.  The CPU performs an AEX by saving the CPU state into a
predefined area inside the enclave and transferring control to a predefined
address outside of 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
platform 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, again using dedicated CPU instructions. SGX uses a cryptographic mechanism to enforce the confidentiality, integrity and
freshness of the evicted EPC pages while they are stored in untrusted memory.
