The lessons learned from working on orthogonal persistence in St Andrews and Adelaide led to an operating system project which was started in 1992. The Grasshopper Persistent Operating System was developed in Adelaide and Sydney in conjunction with Professor John Rosenberg and Frank Henskins of Sydney University. The work was motivated by earlier work by us external pagers under the Mach operating system and work on the Monads Operating System in Newcastle. Monolithic and micro-kernel-based operating systems such as Unix had failed to provide us as persistent system builders with sufficient flexibility. They provide a host of inefficient and often inappropriate abstractions that prevent applications from accessing the hardware to exploit efficiency gains. The Grasshopper project set out to build a new operating system designed to explicitly support orthogonal persistence. Much of the above is still true today and continues to drive OS research.
Grasshopper featured an abstraction over both storage and address spaces called a container. The (persistent) kernel implemented a capability protection mechanism. It also provided a novel checkpointing mechanism that tracked inter-process causal dependencies in the kernel.
Many of the ideas from Grasshopper were incorporated into Charm (1990s) Charm was motivated by a desire to keep all policy and management out of the operating system. This resulted in the concept of a self-managing protection domain. In Charm we embraced the ideas set out in exo-kernels and created an operating system in which the self-managing protection domain is the only building block supplied to the application programmer. Common abstractions such as processes and threads could be efficiently implemented at user level using this building block. We demonstrated that self-managing protection domains could be constructed that supported a modern object-oriented application environment that is not closely coupled with the kernel. This was achieved through the introduction of a software artefact called the Umbrella that abstracts over the low-level aspects of self-management and present a clean object-oriented management interface to the upper layers of software.
It is designed to run Cloud-based applications in a light-weight and secure execution environment. It has a minimal kernel that manages the virtual hardware resources presented by an underlying hypervisor. Currently, Stardust targets the x86-64 computer system architecture and runs on the Xen hypervisor and it is completely written in C.
Stardust features a pre-emptive thread scheduler and supports multiple processors. It provides basic device drivers including a standard TCP/IP network stack and an in-memory file system. It also features standard libraries and supports POSIX threads as well as a number of programming languages including C, C++ and Java. It also provides the ability to provision and execute lambda functions in a distributed environment.
Stardust’s virtual machine image is approximately less than 400 Kilobytes in size. Due to its small size, it can be quickly transmitted across the network and rapidly deployed onto Cloud infrastructures where services are expected to be provisioned on-demand.
Due to the absence of many software components that commonly exist in monolithic environments including a range of unnecessary application interfaces or entry points that can be exploited easily, Stardust has a limited attack surface. It exposes a minimal interface that is determined by the needs of the application service that is linked against the kernel.