Overview
Last updated
Last updated
This documentation site is actively being updated. Currently, it provides an overview of the Stardust operating system and will be enriched with more information soon. The best way to get started is to try out the instructions provided in this installation guide. Please contact us if you think that any resource should be added to this documentation site.
Stardust is a Unikernel operating system designed to run Cloud applications in a protected, single-address space environment. It delegates the management of physical resources to an underlying hypervisor which is treated as a trusted platform. Stardust has a small code base that can be maintained easily, and relies on static linking to combine a minimal kernel with a single application, along with the libraries and associated programming language run-time required for the execution of the application. Due to static linking, an executable binary of Stardust is packaged within an immutable single-purpose virtual machine image. Stardust supports multiple cores, preemptive threads, and basic block and networking drivers, and provides a collection of standard POSIX libraries. It supports a number of programming languages and provides a light-weight Java interpreter which is used for experimental purposes.
Since their inception, monolithic operating systems were designed to provide protection for inter-process communication, multiplex scarce hardware resources onto processes, and present high-level abstractions over these resources. Such systems have limitations in terms of their size and the performance of their loci (the agents of change in the system such as processes and threads) and have security vulnerabilities. Unix-like virtual machines are not optimised for size and thus have a large memory footprint and are slow to deploy and startup. In terms of performance, for an arbitrary program to perform a system operation, it must transfer its locus of control from its address space to that of the kernel using a system call. Transferring control from one address space to another is typically considered an expensive operation that is not getting faster as the speed of machines increase. This is also true of modern software containers as they run within user-level address spaces, and communicate with the kernel using a large number of system calls which increases the performance overhead. Furthermore, these systems present a large attack surface that undermines the execution environment of applications and system services. Such environments therefore cannot guarantee protection or enforce isolation amongst processes against malicious use especially in the face of recent security threats including Meltdown and Spectre attacks.
Unikernels are library operating systems that are specialised to target virtual computer system architectures, which makes them suitable candidates for encapsulating and running Cloud applications. There are a number of arguments for adopting Unikernels but we focus on design, performance, and security which are discussed briefly as follows:
Design: Central to the design model of Unikernels is its simplicity. Occam's razor must be applied wherever possible to preserve the simplicity of the operating system rather than the proliferation of poorly integrated and unnecessary features in the kernel. Simplicity influences the size and memory footprint of the Unikernel. For example, compiling Stardust, our prototype Unikernel, produces a virtual machine appliance which is approximately 60 KBs in size (or less than 200 KBs when linked with a light-weight Java interpreter). Stardust requires 4 MBs of minimum memory to run on a virtualised x86 computer system (64bit).
Performance: Unikernels permit the application code to run within the same address space and execute closer to the hardware resources which provides better performance compared to monolithic operating systems in which the locus of control jumps back and forth between the user and the kernel address spaces. Unikernels reduce the overhead incurred by traditional operating systems by including pre-configured libraries which are only necessary to run the application along with drivers that interact with virtual devices. So there is no need for detecting hardware devices at startup and dynamically loading libraries.
Security: Unikernels execute in a single-address space and therefore they can be sealed during compilation. For example, Stardust can be assembled by statically linking the kernel and the application code to produce an immutable virtual machine appliance that cannot be easily altered to introduce malicious code. This also provides protection against code injections. Unlike monolithic environments, Unikernels are more secure due to the absence of abstractions that facilitate communication between user-level applications and the kernel. Unikernels run a single process and therefore do not require mechanisms to support inter-process communication, lack the notion of system calls, and peculiar features which permit applications to communicate or exchange data with the kernel. Hence, they are seen as more secure and trustworthy software containers.
