What is the Graphene library OS?

A Library OS is a light-weight guest OS, designed to run one application in a VM-like environment. Existing library OSes lack full support of Multi-process abstractions, such as fork, execve, signaling, etc, which are required by many legacy Unix or Linux applications. such as shell scripts, Makefiles, or server applications.

Graphene extends the library OS model to support multi-process applications, and aims to ultimately provide Linux compatibility.

Source code is availalable here.

Graphene library OS slightly modifies the GNU C library to redirect system calls to Graphene as library calls, or uses seccomp to redirect system calls to Graphene. Graphene can support most of the native executables and libraries from Linux platform without modifying the binaries or recompiling the source code. The only prerequisite to run a binary on Graphene is to provide a manifest file which specifies the static environment where the binary can start. A reasonable manifest file usually includes URIs of the binaries, parameters of the file systems, and other important parameters that the system requires.

Graphene library OS is designed to run on top of Linux as its host, although we are working on ports to other host kernels. Graphene is programmed against a narrowed, but generic host ABI---a variant of the Drawbridge library OS, with minimal extensions to support Linux personality and improve performance and security isolation for multi-process applications.

How does Graphene support multi-process applications?

Similar to other library OSes, Graphene implements the operating system APIs, such as system calls of Linux platform, inside the library OS. For a multi-process application, each guest, or picoprocess, has its own library OS instance. Multiple library OSes in an application cooperate to support shared multi-process abstractions such as fork, execve, signaling or even System V message queues and semaphores. Graphene includes a framework for coordinating all of these guest-specific multi-process abstractions using RPC streams across picoprocesses---providing a narrow, easy-to-secure security isolation boundary.

figure 1

Figure 1 shows how signaling and exit notification are serviced in Graphene as an example of multi-process coordination. To exchange the state of signal or exit status, one library OS will send a RPC message over a RPC stream to other library OS. In each library OS, an internal thread called IPC helper thread will listen on all the connection RPC streams, triggering asynchronous events or responding to remote requests. For example, when the IPC helper thread receives a signal or an exit notification, it updates the bookkeeping inside the library OSes, and wakes up appropriate application threads to handle the signal or exit status.

We observe that the primary challenge of coordinating multi-process abstractions across library OSes is to maintain a globally consistent namespace state. Maintaining namespace state requires keeping an consistent mapping from the name of the shared resources to the picoprocesses that manage the resource state. We avoid broadcasting or completely replicating the states to reduce costs. Instead, we choose one of the library OSes as a centralized server of namespace management (these library OSes are called leaders, but still distribute and coordinate the state across multiple library OSes. Although the multi-process abstractions Graphene supports are quite diverse, we are able to identify namespace management as a common theme, and develop a set of tools to simplify implementation of each additional abstraction.

The following is a list of multi-process abstractions that are currently supported in Graphene:

  • fork (with PID allocation) / execve
  • Exit notification / waitpid
  • Signaling
  • /proc/[pid] to get process metadata
  • System V message queues and semaphores

What is the benefit of running applications in Graphene library OS?

Compared to running an application in a VM with a complete legacy guest OS, which requires hundreds of MB to GB of memory, Graphene's memory overheads are closer to a Linux process (tens of MB). Graphene still has higher performance overheads than Linux (which we are working to improve), but maintains the qualitative benefits of virtualization, such as security isolation. Graphene also introduces some useful mechanisms for application sandboxing.

How to obtain Graphene library OS?

Graphene source code and documentation are available at the Graphene source code repository.


This material is based upon work supported by the National Science Foundation under Grants CNS-1149730, CNS-1149229, CNS-1161541, and CNS-1228839.

Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation

Challenges For Scaling Applications Across Enclaves
Jethro G. Beekman,
In Proceedings of the 2nd Workshop on System Software for Trusted Execution (SysTEX '17), Shanghai, China, October 2017.
Graphene-SGX: A Practical Library OS for Unmodified Applications on SGX
Mona Vij,
Proceedings of the 2017 USENIX Annual Technical Conference (ATC '17), Santa Clara, California, July 2017.
Cooperation and Security Isolation of Library OSes for Multi-Process Applications
Harry A. Kalodner,
Daniela Oliveira,
In Proceedings of the 9th European Conference on Computer Systems (EuroSys '14), Amsterdam, The Netherlands, April 2014
Virtualize Storage, Not Disks
In Proceedings of the 14th Workshop on Hot Topics in Operating Systems (HotOS '13), Santa Ana Pueblo, New Mexico, May 2013.