KylinX: A Dynamic Library Operating System for Simplified and Efficient Cloud Virtualization

Abstract

📜 Abstract

Unikernel specializes a minimalistic LibOS and a target application into a standalone single-purpose virtual machine (VM) running on a hypervisor, which is referred to as (virtual) appliance. Compared to traditional VMs, Unikernel appliances have smaller memory footprint and lower overhead while guaranteeing the same level of isolation. On the downside, Unikernel strips off the process abstraction from its monolithic appliance and thus sacrifices flexibility, efficiency, and applicability. This paper examines whether there is a balance embracing the best of both Unikernel appliances (strong isolation) and processes (high flexibility/efficiency). We present KylinX, a dynamic library operating system for simplified and efficient cloud virtualization by providing the pVM (process-like VM) abstraction. A pVM takes the hypervisor as an OS and the Unikernel appliance as a process allowing both page-level and library-level dynamic mapping. At the page level, KylinX supports pVM fork plus a set of API for inter-pVM communication (IpC). At the library level, KylinX supports shared libraries to be linked to a Unikernel appliance at runtime. KylinX enforces mapping restrictions against potential threats. KylinX can fork a pVM in about 1.3 ms and link a library to a running pVM in a few ms, both comparable to process fork on Linux (about 1 ms). Latencies of KylinX IpCs are also comparable to that of UNIX IPCs.

Description

✨ Summary

KylinX extends the Unikernel model with a process-like virtual machine abstraction. It treats the hypervisor as an operating system and each Unikernel appliance as a process, enabling dynamic page mapping and dynamic library mapping while retaining hypervisor-enforced VM isolation. Its page-level mechanisms provide pVM fork and inter-pVM communication through pipes, signals, message queues, and shared memory. Its library-level mechanisms support runtime library linking, online library replacement, and recycling of in-memory domains for faster startup. The prototype modifies MiniOS and the Xen toolstack and enforces restrictions intended to limit security risks from dynamic mappings. (usenix.org)

The evaluation reports approximately 1.3 ms pVM-fork latency, library-linking latency of a few milliseconds, and inter-pVM communication latencies comparable to UNIX IPC. Tests using Redis and a web server report greater applicability and performance than static Unikernel appliances while preserving the isolation model assumed by the system. (usenix.org)

Later research explicitly cites KylinX as prior work on multi-process Unikernels. Iso-UniK compares its fork and pipe performance against KylinX and presents a different design that provides multi-process support using memory-protection keys without requiring hypervisor modifications. (link.springer.com) The position paper The Case for Intra-Unikernel Isolation uses KylinX as an example of implementing processes by spawning separate Unikernel VM instances, while identifying the resulting per-instance memory footprint and address-space-switching costs as motivations for intra-Unikernel isolation. (ssrg.ece.vt.edu) A later presentation on CHERI-based Unikernels lists KylinX among existing approaches that implement POSIX-style process support by using one Unikernel per process and hypervisor-mediated IPC, contrasting it with proposed single-address-space approaches. (cl.cam.ac.uk) The same general architecture also appears as cited prior art in a 2024 patent concerning hypervisor support for multi-process applications, VM cloning, shared pages, and faster Unikernel instantiation. (patents.justia.com)

The available evidence indicates influence primarily as research and architectural prior art. The search found no reliable evidence of broad production deployment by a commercial cloud provider; the project information describes KylinX as a prototype. (nicexlab.com)