\HeadingLevelC{Enclave Eviction}
\label{sec:enclave_eviction}

General-purpose software can be enclaved without source code
changes, provided that it is linked against a runtime (e.g., \textit{libc})
modified to work with Sanctum. Any such runtime would be included in the TCB.

The Sanctum design allows the operating system to over-commit physical
memory allocated to enclaves, by collaborating with an enclave to page some of its DRAM regions to disk. Sanctum does not give the OS visibility into enclave memory accesses,
in order to prevent private information leaks, so the OS must decide the
enclave whose DRAM regions will be evicted based on other activity, such as
network I/O, or based on a business policy, such as Amazon EC2's spot
instances.

Once a victim enclave has been decided, the OS asks the enclave to block a DRAM
region (cf. Figure \ref{fig:dram_region_states}), giving the enclave an opportunity to rearrange data in its RAM
regions. DRAM region management can be transparent to the programmer if handled
by the enclave's runtime.
The presented design requires each enclave to always occupy
at least one DRAM region, which contains enclave data structures and the memory
management code described above. Evicting all of a live enclave's memory
requires an entirely different scheme that is deferred to future work.

The security monitor does not allow the OS to forcibly reclaim a single DRAM
region from an enclave, as doing so would leak memory access patterns.
Instead, the OS can delete an enclave, after stopping its threads, and reclaim
all its DRAM regions. Thus, a small or short-running enclave may well refuse DRAM
region management requests from the OS, and expect  the OS to delete and restart
it under memory pressure.

To avoid wasted work, large long-running enclaves may elect to use demand
paging to overcommit their DRAM, albeit with the understanding that demand
paging leaks page-level access patterns to the OS. Securing this mechanism requires
the enclave to obfuscate its page faults via periodic I/O using oblivious RAM
techniques, as in the Ascend processor \citep{fletcher2012ascend}, applied at
page rather than cache line granularity, and with integrity verification.
This carries a high overhead: even
with a small chance of paging, an enclave must generate periodic page faults,
and access a large set of pages at each period. Using an analytic model, we
estimate the overhead to be upwards of 12ms per page per period for a high-end
10K RPM drive, and 27ms for a value hard drive. Given the number of pages
accessed every period grows with an enclave's data size, the costs are easily
prohibitive. While SSDs may alleviate some of this prohibitive overhead,
and will be investigated in future work, currently Sanctum focuses on securing enclaves
without demand paging.

Enclaves that perform other data-dependent communication, such as targeted I/O
into a large database file, must also use the periodic oblivious I/O to
obfuscate their access patterns from the operating system.
These techniques are independent of application business logic, and
can be provided by libraries such as database access drivers.

Briefly, the OS can ask the security monitor to \textit{freeze} an enclave,
encrypting the enclave's DRAM regions in place, and creating a leaf node in a
hash tree. When the monitor \textit{thaws} a frozen enclave, it uses the hash
tree leaf to ensure freshness, decrypts the DRAM regions, and
\textit{relocates} the enclave, updating its page tables to reflect new owners
of relevant DRAM regions. The hash tree is managed by the OS using an approach
similar to SGX's version array page eviction.
