\HeadingLevelB{The XOM Architecture}
\label{sec:sgx_related_xom}

The execute-only memory (XOM) architecture \citep{lie2000xom} introduced the
approach of executing sensitive code and data in isolated containers managed by
untrusted host software. XOM outlined the mechanisms needed to isolate a
container's data from its untrusted software environment, such as saving the
register state to a protected memory area before servicing an interrupt.

XOM supports multiple containers by tagging every cache line with the
identifier of the container owning it, and ensures isolation by disallowing
memory accesses to cache lines that don't match the current container's
identifier. The operating system and the untrusted applications are considered
to belong to a container with a null identifier.

XOM also introduced the integration of encryption and HMAC functionality in
the processor's memory controller to protect container memory from physical
attacks on DRAM. The encryption and HMAC functionality is used for all cache
line evictions and fetches, and the ECC bits in DRAM are repurposed to
store HMAC values.

XOM's design cannot guarantee DRAM freshness, so the software in its containers
is vulnerable to physical replay attacks. Furthermore, XOM does not protect a
container's memory access patterns, meaning that any piece of malicious
software can perform cache timing attacks against the software in a container.
Last, XOM containers are destroyed when they encounter hardware exceptions,
such as page faults, so XOM does not support paging.

XOM predates the attestation scheme described at the beginning of the section, and relies on a modified
software distribution scheme instead. Each container's contents are encrypted
with a symmetric key, which also serves as the container's identity. The
symmetric key, in turn, is encrypted with the public key of each CPU that is
trusted to run the container. A container's author can be assured that the
container is running on trusted software by embedding a secret into the
encrypted container data, and using it to authenticate the container. While
conceptually simpler than software attestation, this scheme does not allow the
container author to vet the container's software environment.
