\HeadingLevelA{The Software Isolation Container (As Exemplified by Intel's SGX)}
\label{sec:sgx_model}

Among prior work that failed to achieve meaningful security guarantees in a realistic setting, two shortcomings are prevalent: an inability to protect against an impersonating attacker, and the inclusion of large amounts of vulnerable system software in the trusted computing base.
In the context of remote computation, the system's privacy guarantees affect the system's ability to guarantee integrity: an attacker capable of learning the trusted system's secret keys can trivially defeat any protection offered by the system by emulating it (convincing the remote user that an arbitrary malicious system is the trusted system she intends to communicate with).

Another common failure is the inclusion of excessive system software in the trusted computing base.
As further discussed in Section~\ref{sec:system_software_attacks}, a modern hypervisor (Xen) weighs in at 150 thousand lines of code, with the Linux kernel reaching a staggering 17 \emph{million} lines of code. Such large code bases are (at the time of this writing) far too large for formal verification, and are dense with implementation errors. Indeed, both reveal dozens of security vulnerabilities every year, and should not be included in a trusted computing base of any security-critical application.
Even if a system is able to guarantee the integrity and privacy of a given application, the inclusion of millions of lines of buggy code in the trusted computing base makes the system's claims to security largely irrelevant.

A practically secure system trusts only the software needed to perform the security-critical task, as well as a hardware platform able to enforce its security policy and traceable to a trustworthy manufacturer.
While an application cannot reasonably be secure against its own accidental or deliberate leaks of information, security-critical applications are expected to be scrutinized, and may be formally verified.
A simple, easy-to-understand threat model improves the programmers' ability to write secure software, as a simple threat model simplifies the invariants the system must obey in order to be secure.

While Intel's Software Guard Extensions fall short of this ideal (as discussed in Part II of this work), the system does present a very attractive programming model: a private process with privacy and integrity guarantees assuming the software of the process itself is not vulnerable.
The central concept of SGX\footnote{
As mentioned earlier, this work discusses the original version of SGX, also referred to as SGX 1.}
%While SGX 2 brings very useful improvements for enclave authors, it is a small
%incremental improvement, from a design and implementation standpoint.
%After understanding the principles behind SGX 1 and its security properties, the
%reader should be well equipped to face Intel's reference documentation and
%learn about the changes brought by SGX 2.}
is the \textit{enclave}, a protected environment
that contains the code and data pertaining to a security-sensitive computation.

SGX-enabled processors provide trusted computing by isolating each enclave's
environment from the untrusted software outside the enclave, and by
implementing a software attestation scheme that allows a remote party to
authenticate the software running inside an enclave. SGX's isolation mechanisms
are intended to protect the confidentiality and integrity of the computation
performed inside an enclave from attacks coming from malicious software
executing on the same computer, as well as from a limited set of physical
attacks.

Given that SGX is an available, documented example of an enclave-capable system, this section presents the programming model employed by the enclave primitive, as exemplified by Intel's SGX.
In Part II of this work, we rely on this discussion to motivate the MIT Sanctum project, and present its hardware and software design to present a stronger security argument with an equivalent programming model.

This section summarizes the SGX concepts that make up a mental model that is
sufficient for programmers to author SGX enclaves and to add SGX support to
existing system software. Unless stated otherwise, the information in this
section is backed up by Intel's Software Developer Manual (SDM). The following
section builds on the concepts introduced here to fill in some of the missing
pieces in the manual, and analyzes some of SGX's security properties.


\input{text/sgx/physical_memory.tex}
\input{text/sgx/enclave_layout.tex}
\input{text/sgx/lifecycle.tex}
\input{text/sgx/threads.tex}
\input{text/sgx/eviction.tex}
\input{text/sgx/measurement.tex}
\input{text/sgx/versioning.tex}
%\input{text/sgx/rsa_check.tex}
\input{text/sgx/attestation.tex}
\input{text/sgx/launch_policy.tex}
