Graphene Library OS
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. We plan to publicly release the Graphene source code soon, allowing other researchers to more easily experiment with library OS designs for Linux applications.
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 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
- /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?
We will release the source code of Graphene library OS as soon as possible. For the latest progress and more technical details, please see the Graphene source code repository.
A number of people have contributed code to the Graphene libOS project, and we hope more will continue to contribute features and bugfixes.
- Chia-Che Tsai
- Kumar Saurabh Arora
- Nehal Bandi
- Bhushan Jain
- Bill Jannen
- Jitin John
- Harry Kalodner
- Vrushali Kulkarni
- Daniela Oliveira
- Don Porter
- Anchal Agarwal
- Amit Arya
- Imran Brown
- Gurpreet Chadha
- Naveen Kalaskar
- Manikantan Subramanian
- Sourabh Yerfule
"Cooperation and Security Isolation of Library OSes for Multi-Process Application", appearing in EuroSys 2014. See the paper here.
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