\HeadingLevelB{Intel SGX}
\label{sec:sgx_related_sgx}

Intel's Software Guard Extensions (SGX)~\citep{mckeen2013sgx, anati2013sgx,
hoekstra2013sgx} implements secure containers for applications without making
any modifications to the processor's critical execution path. SGX does not
trust any layer in the computer's software stack (firmware, hypervisor, OS).
Instead, SGX's TCB consists of the CPU's microcode and a few privileged
containers. SGX introduces an approach to solving some of the issues raised by
multi-core processors with a shared, coherent last-level cache.

SGX does not extend caches or TLBs with container identity bits, and does not
require any security checks during normal memory accesses. As suggested in the
TrustZone documentation, SGX always ensures that a core's TLBs only contain
entries for the container that it is executing, which requires flushing the CPU
core's TLBs when context-switching between containers and untrusted software.

SGX follows Bastion's approach of having the untrusted OS manage the page
tables used by secure containers. The containers' security is preserved by a
TLB miss handler that relies on an inverted page map (the EPCM) to reject
address translations for memory that does not belong to the current container.

Like Bastion, SGX allows the untrusted operating system to evict secure
container pages, in a controlled fashion. After the OS initiates a container
page eviction, it must prove to the SGX implementation that it also switched
the container out of all cores that were executing its code, effectively
performing a very coarse-grained TLB shootdown.

SGX's microcode ensures the confidentiality, authenticity, and freshness of
each container's evicted pages, like Bastion's hypervisor. However, SGX relies
on a version-based Merkle tree, inspired by Aegis \citep{suh2003aegis}, and adds
an innovative twist that allows the operating system to dynamically shape the
Merkle tree. SGX also shares Bastion's and Aegis' vulnerability to memory
access pattern leaks, namely a malicious OS can directly learn a container's
memory accesses at page granularity, and any piece of software can perform
cache timing attacks.

SGX's software attestation is implemented using Intel's Enhanced Privacy ID
(EPID) group signature scheme \citep{brickell2009epid}, which is too complex for
a microcode implementation. Therefore, SGX relies on an assortment of
privileged containers that receive direct access to the SGX processor's
hardware keys. The privileged containers are signed using an Intel private key
whose corresponding public key is hard-coded into the SGX microcode, similarly
to TXT's SINIT ACM.

As SGX does not protect against cache timing attacks, the privileged enclave's
authors cannot use data-dependent memory accesses. For example, cache attacks
on the Quoting Enclave, which computes attestation signatures, would provide
an attack with a processor's EPID signing key and completely compromise SGX.

Intel's documentation states that SGX guarantees DRAM confidentiality,
authentication, and freshness by virtue of a Memory Encryption Engine (MEE).
The MEE is informally described in an ISCA 2015
tutorial~\citep{intel2015iscasgx}, and in more detail in \citep{gueron2016sgxmee}.
It appears that SGX provides the same
protection against physical DRAM attacks that Aegis and Bastion provide.
