PaperlayerView exact revision on arXiv

Source-linked AI summary

Occlum: Secure and Efficient Multitasking Inside a Single Enclave of Intel SGX

Youren Shen, Hongliang Tian, Yu Chen, Kang Chen, Runji Wang, Yi Xu, Yubin Xia

arXiv:2001.07450v1cs.OScs.ARcs.CR

TL;DR

Existing SGX LibOSes do not provide multitasking that is both secure and efficient. Occlum uses SIPs, MMDSFI, and an independent verifier to isolate processes while sharing one enclave address space, outperforming the state-of-the-art multitasking SGX LibOS by up to 6,600× on micro-benchmarks and 500× on application benchmarks.

  • Problem

    Existing SGX LibOSes cannot support multitasking both securely and efficiently, although virtually any non-trivial application requires multiple processes.

  • Method

    Occlum implements LibOS processes as SIPs, enforces their isolation with MMDSFI, and uses an independent verifier to check ELF binaries against MMDSFI policies.

  • Results

    Occlum outperforms the state-of-the-art SGX LibOS by up to 6,600× on micro-benchmarks and up to 500× on application benchmarks.

  • Takeaways & Limitations

    Safely sharing one enclave address space enables fast process startup, low-cost IPC, and a writable encrypted file system.

  • Takeaways & Limitations

    Network operations are delegated mostly to the host OS, so secure network I/O requires user-level encryption such as TLS.

Abstract

from arXiv · show

Intel Software Guard Extensions (SGX) enables user-level code to create private memory regions called enclaves, whose code and data are protected by the CPU from software and hardware attacks outside the enclaves. Recent work introduces library operating systems (LibOSes) to SGX so that legacy applications can run inside enclaves with few or even no modifications. As virtually any non-trivial application demands multiple processes, it is essential for LibOSes to support multitasking. However, none of the existing SGX LibOSes support multitasking both securely and efficiently. This paper presents Occlum, a system that enables secure and efficient multitasking on SGX. We implement the LibOS processes as SFI-Isolated Processes (SIPs). SFI is a software instrumentation technique for sandboxing untrusted modules (called domains). We design a novel SFI scheme named MPX-based, Multi-Domain SFI (MMDSFI) and leverage MMDSFI to enforce the isolation of SIPs. We also design an independent verifier to ensure the security guarantees of MMDSFI. With SIPs safely sharing the single address space of an enclave, the LibOS can implement multitasking efficiently. The Occlum LibOS outperforms the state-of-the-art SGX LibOS on multitasking-heavy workloads by up to 6,600X on micro-benchmarks and up to 500X on application benchmarks.

1 Introduction

Occlum addresses the security and efficiency gap in multitasking SGX LibOSes by placing isolated processes in one enclave address space and verifying their isolation. Its implementation combines SIPs, MMDSFI, and an independent verifier to improve multitasking performance and usability.

  • Multitasking is indispensable because non-trivial applications commonly require multiple processes and dependent services.
  • Existing SGX LibOSes lack multitasking that is both secure and efficient, while enclave-per-process designs make creation, IPC, and synchronization costly.Graphene-SGX process creation is reported to be nearly 10,000× slower than Linux.
  • Occlum implements LibOS processes as SFI-Isolated Processes sharing one enclave address space, enabling intra-enclave process and LibOS isolation.The approach uses software instrumentation to sandbox process domains.
  • Shared-address-space SIPs provide fast process startup, low-cost IPC, and a writable encrypted file system.
  • Up to 6,600× higher performance on micro-benchmarks and up to 500× on application benchmarks were achieved, while MMDSFI prevented all RIPE memory attacks.MMDSFI incurred an average of 36% overhead on CPU-intensive benchmarks.
  • MMDSFI enforces SIP isolation, while an independent verifier statically checks ELF binaries against MMDSFI security policies.The verifier allows the large, complex toolchain to be excluded from the Trusted Computing Base.

2 Background and Related Work

The background establishes SGX constraints, limitations of existing multitasking LibOS isolation, and the motivation for MMDSFI. MMDSFI uses MPX bounds to support flexible domain isolation inside an enclave.

  • 2 Background: SGX enclaves protect code and data from software and hardware attacks outside the enclave, but enclave creation is expensive.
  • 2 Background: SGX 1.0 cannot dynamically add, remove, or change enclave-page permissions after initialization, motivating Occlum’s SGX 1.0 implementation for compatibility.
  • 2 Background: SGX lacks suitable trusted hardware mechanisms for partitioning an enclave into smaller domains, so Occlum turns to SFI for intra-enclave isolation.
  • 2.2 Multitasking: Existing LibOSes either lack process isolation or use enclave-isolated processes that incur performance and usability issues.
  • 2.3 Intel MPX and SFI: MMDSFI targets many processes inside an enclave without constraints on domain number, addresses, or sizes.MPX bound registers can represent any domain address or size, and CPU thread switching preserves their state.
  • 2.3 Intel MPX and SFI: MMDSFI fully leverages MPX to provide flexible domain counts, addresses, and sizes rather than merely reducing SFI overhead.

3 SFI-Isolated Processes (SIPs)

Occlum uses SFI-Isolated Processes (SIPs) to isolate multiple processes within one enclave address space. This design improves process creation, IPC, and writable encrypted file-system support while requiring spawn instead of fork.

  • 3.1 Threat Model and Security Goals: SIPs protect processes from one another and from the LibOS under a threat model including compromised infrastructure and vulnerable SIPs.Occlum assumes the LibOS is correctly implemented and excludes Iago, denial-of-service, side-channel, and covert-channel attacks.
  • 3.2 Advantages of SIPs: SIPs share one enclave address space and one LibOS instance, enabling fast startup, low-cost IPC, and a writable encrypted file system.SIPs avoid new enclave creation, attestation, and encrypted process-state transfer; IPC uses direct data copying.
  • 3.3 Feasibility of SIPs: Occlum uses spawn instead of fork because fork’s shared-address-space semantics conflict with its single-address-space design.The paper reports that most fork-and-exec uses can be replaced with spawn, and some fork-only applications can be rewritten to use spawn-like APIs.
  • 3.3 Feasibility of SIPs: The paper characterizes spawn as superior to fork, citing recent work that argues fork’s continued existence holds back systems research.This is presented as motivation for the process-creation interface chosen by Occlum.

4 MPX-Based, Multi-Domain SFI (MMDSFI)

MMDSFI isolates SIPs by instrumenting untrusted code with MPX-based memory checks and control-flow restrictions. Its guard regions and range-analysis optimizations reduce the cost of enforcing these policies.

  • 4.1 Overview: MMDSFI enforces domain isolation by restricting memory accesses to [D.begin, D.end) and control transfers to [C.begin, C.end).Invalid instructions must be prevented or detected; instrumentation inserts checks or rewrites unsafe instructions.
  • 4.1 Overview: Each domain places code in region C and data in region D, with unmapped guard regions surrounding D to trigger exceptions and simplify instrumentation.The LibOS initializes MPX bound registers for the data range and cfi_label range.
  • 4.2 Instrumentation: mem_guard confines unsafe memory accesses with two MPX bound checks, while cfi_label and cfi_guard constrain indirect control transfers to valid targets.cfi_guard tests whether a target contains the domain-specific cfi_label value and raises an exception otherwise.
  • 4.2 Instrumentation: MMDSFI uses coarse-grained control-flow integrity because direct transfers can be checked statically, whereas indirect transfers require runtime checks.The design also prevents jumps into instruction or pseudo-instruction interiors, which could bypass instrumentation.
  • 4.3 Optimizations: Range analysis enables redundant-check elimination and loop-check hoisting using the guard regions surrounding each data region.Loop hoisting reduces a repeated mem_guard to one execution per loop when address changes remain within a guard-region size.
  • 4.3 Optimizations: The two range-analysis optimizations reduce MMDSFI overhead to an acceptable level.The paper identifies these optimizations as sufficient for the reported overhead reduction.

5 Binary Verification

The Occlum verifier statically checks ELF binaries through disassembly, instruction-set, control-transfer, and memory-access verification. Passing all four stages supports formal guarantees for control transfers and memory accesses.

  • 5.1 Verifier Overview: The independent verifier accepts an ELF binary only if all four verification stages pass, establishing MMDSFI compliance for execution inside Occlum.The stages are complete disassembly, instruction-set verification, control-transfer verification, and memory-access verification.
  • 5.2 Stage 1: Stage 1 disassembles the binary and generates R, the set of all reachable instructions, using cfi_labels as reliable starting points.The paper states that cfi_labels make the disassembly completely accurate for binaries that pass the remaining verifier stages.
  • 5.3 Stage 2: Stage 2 rejects dangerous SGX, MPX, and miscellaneous instructions that could perform privileged tasks or modify security-relevant processor state.The stage scans R for instructions such as eexit, bndmk, xrstor, and wrfsbase.
  • 5.4 Stage 3: Stage 3 classifies control transfers into four categories and checks each category against its verification criteria.The resulting theorem states that every control transfer in a verified domain complies with MMDSFI’s control-transfer policy.
  • 5.6 Security Guarantees: The verifier proves that register-based indirect transfers can target only cfi_labels within the domain.This lemma supports the broader theorem that all verified control transfers comply with the MMDSFI policy.
  • 5.5 Stage 4: Stage 4 builds a CFG, performs cfi_label-aware range analysis, and verifies or rejects every memory-access instruction across five categories.Theorem 5.3 states that every memory access in a verified domain complies with MMDSFI’s memory-access policy.

6 Library OS

The Occlum LibOS connects verified SIPs to system services through a controlled loader, trampoline-based syscalls, shared process resources, and encrypted storage. Network I/O remains dependent on user-level encryption for security.

  • 6.1 ELF Loader: The ELF loader verifies and signs binaries, rewrites cfi_labels, inserts the sole LibOS-call trampoline, and initializes MPX bounds.These responsibilities connect binary verification and MMDSFI domain setup to SIP execution.
  • 6.2 Syscall Interface: LibOS system calls use a trampoline that performs sanity checks, switches stacks and thread-local storage, and validates return targets.SIPs are sandboxed by MMDSFI, so system calls are their path to LibOS functionality.
  • 6.4 Process Management: Occlum maps SIPs one-to-one to SGX threads and implements IPC through shared LibOS data structures.The host OS transparently schedules the corresponding SGX threads.
  • 6.5 File Systems: All SIPs share a unified LibOS file-system view, while Occlum encrypts file data, metadata, and directories.The design supports writable encrypted storage within the shared LibOS instance.
  • 6.3 Networking: Network operations are mostly delegated to the host OS, so network I/O is not secure by default and requires user-level encryption such as TLS.The LibOS performs redirection, bookkeeping, and sanity checks for networking.

7 Security Analysis

Occlum’s MMDSFI and LibOS enforce isolation against code injection and ROP attacks by constraining writable code paths, control transfers, and verified execution behavior.

  • Occlum’s security analysis examines whether code injection and ROP attacks can penetrate MMDSFI and LibOS isolation.These are treated as two common attack classes against inter-process and process-LibOS isolation.
  • Occlum prevents code injection because SIPs cannot write executable pages, only the LibOS can modify them, and system calls restrict memory-permission abuse.A malicious SIP therefore cannot inject arbitrary code to bypass isolation.
  • Static coarse-grained CFI cannot fully prevent ROP attacks, so MMDSFI instead restricts jumps to cfi_labels and relies on verifier coverage.These restrictions reduce useful gadgets, while verifier analysis covers gadget combinations under the security policies.
  • Despite the residual difficulty of preventing ROP attacks generally, the analysis concludes that ROP cannot violate MMDSFI and LibOS isolation.

8 Implementation

Occlum combines a toolchain, verifier, and Rust-based LibOS to instrument, validate, and run applications within its MMDSFI design.

  • Occlum consists of a toolchain, an independent verifier, and a LibOS, with more than 20,000 lines of source code overall.The implementation includes Rust for the LibOS, C++ for the toolchain, and Python for the verifier.
  • The LLVM-based toolchain instruments control transfers and memory accesses, applies range-analysis optimizations, and links ELF binaries compatible with MMDSFI.The linker separates code and data segments and reserves a 4KB guard-region gap.
  • Modified musl libc routes process creation through Occlum’s spawn system call instead of vfork and execve.
  • The verifier uses Zydis and PyVEX to decode x86-64 instructions and represent their semantics for static checking.
  • The LibOS is mostly written in Rust, uses Intel and Rust SGX SDKs, and provides host-side utilities for encrypted file-system images.Rust is used to reduce the likelihood of low-level memory-safety bugs in the LibOS.

9 Evaluation

Evaluation compares Occlum with Linux and Graphene-SGX across applications, system calls, security, and MMDSFI overhead, showing strong multitasking gains with encryption and instrumentation costs.

  • Evaluation goals: The evaluation asks whether Occlum improves multi-process applications, system-call performance, application security, and MMDSFI overhead.Experiments compare Occlum with Linux and Graphene-SGX.
  • 9.1 Application benchmarks: Occlum is nearly 500× faster than Graphene-SGX on Fish, although its 19.5ms runtime is 13.9× slower than Linux’s 1.4ms.Fish is a process-intensive shell workload.
  • 9.1 Application benchmarks: Occlum is 3.6×–9.2× slower than Linux but 3.82×–42× faster than Graphene-SGX across the three GCC compilation workloads.Compilation times range from 229ms to 3.0s on Occlum.
  • 9.1 Application benchmarks: 9% overhead is reported for Occlum’s peak Lighttpd throughput relative to Linux, compared with 10% for Graphene-SGX.
  • 9.2 System call benchmarks: 97us makes Occlum 1.6× faster than Linux and over 6,600× faster than Graphene-SGX for 14KB process creation.For a 14MB binary, Occlum takes 63ms and is 13× faster than Graphene-SGX.
  • 9.2 System call benchmarks: Occlum’s IPC throughput is on par with Linux and over 3× higher than Graphene-SGX, while encrypted file I/O incurs 39% read and 18% write overhead versus Ext4.
  • 9.3 Security: Occlum prevents all code injection and ROP attacks in RIPE, whereas Graphene-SGX still permits some attacks under both stack-protection settings.Return-to-libc attacks still succeed on Occlum.
  • 9.3 MMDSFI benchmarks: 36.6% is MMDSFI’s average overhead on SPECint2006 CPU-intensive workloads.Range-analysis optimization is evaluated as one source of overhead reduction alongside control-transfer and memory-access confinement.

10 Conclusions

Occlum enables secure and efficient multitasking by isolating SIPs with MMDSFI and an independent verifier while allowing them to share one enclave address space.

  • Occlum implements LibOS processes as SIPs, introduces MMDSFI, and uses an independent verifier to ensure MMDSFI’s security guarantees.SIPs safely share a single enclave address space, enabling efficient multitasking.
  • Experimental results show that Occlum significantly outperforms the state-of-the-art multitasking SGX LibOS.

A.1 Abstract

Occlum’s artifacts provide a scripted workflow for building and evaluating its LibOS and toolchain, including multitasking-oriented benchmarks. The artifacts require Intel x86-64 CPUs with SGX and MPX support and represent an early project version.

  • Occlum’s artifacts include the toolchain, LibOS, environment setup scripts, and benchmark execution scripts.
  • The artifacts require Intel x86-64 CPUs with SGX and MPX support, and the tested environment used Ubuntu 16.04 with kernel 4.15.0-65-generic.
  • The archived artifacts are from an early Occlum version, and users are recommended to test the latest project version instead.
  • The workflow covers dependency installation, LibOS and toolchain builds, and macro- and micro-benchmark execution.
  • The macro-benchmark suite includes fish, GCC, and lighttpd, with lighttpd supporting single-threaded and multithreaded server modes.
  • The lighttpd benchmark reports latency and throughput under different numbers of concurrent clients.
  • The micro-benchmarks measure process-creation latency and IPC throughput.
Loading 2001.07450v1…