Overview of the Singularity Project

What kind of paper is this?

• Describes a large broad project and the context in which that project was undertaken.
• Once again, I love that they really pose this as a research question, "what would a software platform look like if it was designed from scratch with the primary goal of dependability?"

The Story

• Once upon a time, people built computers and software to let people use those computers. The world was an unconnected, safe space, where no one dared tamper with said hardware or software. But so much changed! Today, computers are attached to networks with millions or billions of devices. Bad things happen. Some clever folks at Microsoft decided to build a system that leverages modern software technology such as type safe languages, verification, formal specification, and defect detection, to build a truly dependable system. This allowed everyone to live happily ever after.

Special Sauce

• Software-Isolated Processes (SIPs).
• SIPs have strong interfaces, failure isolation, and information hiding.
• Replace processes.
• SIPs have object spaces, not address spaces.
• Given, "A key experiment in Singularity is to construct an entire operating system using SIPs and demonstrate that the resulting system is more dependable than a conventional system. " I expect to see an evaluation of this. (But alas, the eval is performance. Nonetheless, they explain this, "On the other hand, this paper does not validate our goal of increased dependence. Measuring that aspect of a system is significantly more challenging than performance. We do not yet have results for Singularity."
• Every device driver, system process, application, and extension runs in its own SIP and communicates over channels that provide limited and appropriate functionality
• SIPs can each have their own runtime (they start to feel a bit like libOSs at this point)

Applications

• This might be the first system that combines package management (i.e., application management) with the OS. This seems like a really nice feature.
• Applications can also be security principals, which also seems really nice.

Singularity OS Architecture (pssst, it's a microkernel)

• Kernel
• SIPs
• Channels
• Security
  • Code is either trusted or verified
  • If code can't be verified, then you have to tag it as trusted. (HAL, parts of the kernel, and parts of the runtime)
  • I would have liked a line count breakdown.

The Singularity Kernel

• Privileged
• Controls access to hardware
• Allocates and reclaims memory
• Creates and schedules therads
• Provides IPC and synchronization
• Manages IO

Process Model

• Singularity has a single virtual address space
• Divided into kernel objects, object space for each process, and exchange heap (for channel data)
• Cross object space pointers must live in the exchange heap (eases GC)
• Each process (SIP) has its own garbage collector

Channels

• Behaviorally typed via contract
• Messages also strictly typed
• Asynchronous send
• Receive is synchronous (block for a specific message)
• Data sent over a channel changes ownership

Sing#

• Derived from Spec# which is derived from C#
• Pre- post-conditions and object invariants
• Statically verified and runtime checks
• Why new language: needed to incorporate message passing as first class entity
• Channel contracts: pre condition + post condition + state machine definition

Evaluation

• They set out to build a secure system and built a fast one.
• How would you evaluate security? Or dependability?
• Microbenchmarks: Singularity is largely much faster (no HW address space crossings).
• IO Bandwidth: largely a wash
• SpecWeb: They are pretty honest that: A) their system is not stable, B) It's slow on SpecWeb, C) Boxwood is problematic, D) its latency might be OK. (Ironically, the only singularity publication that I know about is Boxwood).
• Singularity processes contain their own runtime and are large.
• In contrast to their file size, the memory usage appears relatively modest.

Feature Analysis

1. Features that are common practice
   • Managed languages.
2. Features that are not used and should stay that way
3. Features that are not used but should be reconsidered
   • A single mechanism for isolation and extensibility.
   • Making the system responsible for application management (making applications first class entities).
   • Modularity with strong interfaces and specification.
   • ABI Versioning
   • Applications as security principals.
4. Features for which the jury is out
   • Microkernel
   • Single address space
   • Sharing: This is the anti-multics OS -- there is no sharing between processes; this seems to potentially be a limitation.
   • Integrating transient and persistent names into the same namespace (the file system is a subtree of the name space).