An enclave stores its code and private data in parts of DRAM that
have been allocated by the OS exclusively for the enclave's use (as does SGX), which are
collectively called \textbf{the enclave's memory}. Consequently, we refer to
the regions of DRAM that are not allocated to any enclave as \textbf{OS
memory}. The security monitor tracks DRAM ownership, and ensures that no piece
of DRAM is assigned to more than one enclave.

Each Sanctum enclave uses a range of virtual memory addresses (EVRANGE) to
access its memory. The enclave's memory is mapped by the enclave's own page
tables, which are stored in the enclave's memory
(Figure~\ref{fig:enclave_page_tables}). This makes private the page table dirty and accessed bits, which can reveal memory access patterns at
page granularity. Exposing an enclave's page tables to the untrusted OS leaves
the enclave vulnerable to attacks such as \citep{xu2015pagefaults}.

The enclave's virtual address space outside EVRANGE is used to access its host
application's memory, via the page tables set up by the OS. Sanctum's hardware
extensions implement dual page table lookup (\S~\ref{sec:pmh_walker_input}),
and make sure that an enclave's page tables can only point into the enclave's
memory, while OS page tables can only point into OS memory
(\S~\ref{sec:pmh_walker}).

\begin{figure}[htb]
  \centering
  \includegraphics[width=80mm]{figures/enclave_page_tables.pdf}
  \caption{Per-enclave page tables.}
  \label{fig:enclave_page_tables}
%\EndFigure
\end{figure}

Sanctum supports multi-threaded enclaves, and enclaves must appropriately provision for
thread state data structures. Enclave threads,
like their SGX cousins, run at the lowest privilege level (user level in
RISC-V), meaning a malicious enclave cannot compromise the OS. Specifically,
enclaves may not execute privileged instructions; address translations that
use OS page tables generate page faults when accessing supervisor pages.

The per-enclave metadata used by the security monitor is stored in dedicated
DRAM regions (\textbf{metadata regions}), each managed
at the page level by the OS, and each includes
a page map that is used by the security monitor to verify the OS' decisions (much like the EPC and EPCM in SGX, respectively).
Unlike SGX's EPC, the metadata region
pages only store enclave and thread metadata. Figure~\ref{fig:enclave_layout}
shows how these structures are weaved together.

\begin{figure}[hbt!]
  \centering
  \includegraphics[width=80mm]{figures/enclave_layout.pdf}
  \caption{Enclave layout and data structures.}
  \label{fig:enclave_layout}
%\EndFigure
\end{figure}
