![](https://csdnimg.cn/release/download_crawler_static/15137355/bg3.jpg)
SGX thread management.
Every SGX thread has a thread
control structure (TCS) in the enclave, which cannot be ac-
cessed by software. CPU will exit enclave when interrupts or
exceptions occur, which is known as asynchronous enclave
exit (AEX). During an AEX, CPU stores execution context of
a thread to the state save area (SSA) and updates the current
SSA pointer to point to this SSA. SSAs are pre-allocated in
TCS during enclave initialization. They are not in any thread
local storage. For resuming an SGX thread from AEX, CPU
will find the corresponding SSA from TCS and restore its
execution context.
2.2. Library OSes for Intel SGX
We compare Occlum with the state-of-the-art LibOSes for
SGX—i.e., Haven [
22
], Scone [
19
], Panoply [
60
], and
Graphene-SGX [63]—in three dimensions.
Compatibility.
An SGX LibOS may be compatible with
legacy applications at either binary or code level. Haven
and Graphene-SGX are binary level compatible while Scone,
Panoply and Occlum are source code level compatible via
cross compilers.
We argue that the code-level compatibility is acceptable
for most use cases since it has eliminated most of the efforts
required to port applications for SGX. And even a binary-
compatible SGX LibOS sometimes demands recompilation so
that the legacy source code can be modified to work around the
hardware limitatations of SGX or the system call limitations
of the LibOS. Futhermore, the recompilation of source code
provides the opportunity to integrate SGX-specific, compiler-
based hardening techniques [52, 49].
Multitasking.
Existing SGX LibOSes do not support mul-
titasking, or cannot do so both securely and efficiently. Haven
supports multitasking in a single-address-space architecture
like Occlum; but it lacks isolation for its LibOS processes.
Scone does not support multitasking. Graphene-SGX and
Panoply support multitasking with EIPs, but suffer from per-
formance and usability issues (§3.2).
TCB sizes.
As Haven reuses the source code of Draw-
bridge [
54
], it ends up with a huge TCB. The Panoply and
other three LibOSes including Occlum are written from scratch
and thus absent of unnecessary OS functionalities. This results
in small TCBs and thus small attack surfaces.
2.3. Intel MPX and SFI
Intel Memory Protection Extensions (MPX) [
43
] is a set of
extensions to the x86 instruction set architecture to provide
bound checking at runtime. It provides four bound registers
bnd0
-
bnd3
. Each bound register stores a pair of 64-bit
values, one for the lower bound and the other for the upper
bound. Two instructions,
bndcl
and
bndcu
are introduced
to check a given address against a bound register’s lower and
upper bound, respectively. If the check fails, an exception will
be raised by the CPU. These four bound registers are saved
Table 1: A comparison between SIPs and EIPs.
EIPs
SIPs
Process creation Expensive Cheap
IPC Expensive Cheap
Shared file systems Read-only Writable
and restored when AEX occurs and enclave resumes from
AEX [46]. Occlum does not use bound tables in MPX.
Software Fault Isolation (SFI) [
64
] is a software instrumen-
tation technique for sandboxing untrusted modules (called
domains). Existing SFI schemes have some limitations on
the number, addresses, or sizes of domains to simplify their
designs. For example, the well-studied SFI scheme Native
Client [
58
] requires two 40GB unmapped memory regions
around a 4GB-size domain. PittSFIeld [
51
] only supports at
most 64 − n domains of n-bit address space on x86-64.
Our SFI scheme MMDSFI intends to sandbox a (potentially)
large number of processes inside the limited address space of
an enclave. MMDSFI tries to put no constraints on the number,
addresses, or sizes of domains. We find two advantages of
using MPX registers as domains’ bound.
1. Bound registers can present any address and any size for
a domain.
2. During thread switching, bound registers are saved by
SGX hardware as thread context. Thus, the number of domains
depends on the memory size.
Existing MPX-enabled SFI systems [
47
,
23
,
53
,
33
] build
one sandbox for one domain and use MPX only for reducing
the overhead of SFI. MMDSFI fully leverages MPX’s advan-
tages and achieves flexibility on the number, addresses, and
sizes of domains.
3. SFI-Isolated Processes (SIPs)
In this section, we give an overview of SIPs by first describ-
ing its threat model, then highlighting its advantages over
traditional EIPs, and finally discussing its feasibility on SGX.
3.1. Threat Model and Security Goals
We assume that attackers can take full control over the hyper-
visor, host OS, and host applications on the target machine.
SIPs are assumed to be benign (at least when loaded by the
LibOS), otherwise their binaries would have been rejected by
our verifier. However, SIPs may have security vulnerabilities
and be compromised by attackers. We also assume that attack-
ers can control both the malicious codes outside the SGX and
some malicious SIPs at the same time to attack other SIPs.
Occlum tries to isolate in-enclave SIPs. Specifically, we
aim to enforce the following two kinds of isolation: 1) Inter-
process isolation, which protects an SIP from other SIPs; and
3