Computer Science Operating Systems

Singularity – Microsoft’s Experimental OS

What would happen if we will write a new OS from scratch right now? can we do it better? can we improve security and robustness? can we prevent unexpected interactions between applications?

“what would a software platform look like if it was designed from scratch with the primary goal of dependability?” [1]

These are the type of questions that the Microsoft Research team was trying to answer around 18 years ago and it was then when they came up with a pretty cool name for their new OS — Singularity.

Goals

Singularity was aimed to eliminate some of the shortcomings of existing operating systems such as

  • General security vulnerabilities
  • Failures due to extensions, drivers, add-ons.
  • Unexpected interactions between apps
  • Lack of robustness

Strategy

  • Utilize a safe programming language — no more of C’s shenanigans, we don’t want to “cook” pointers out of integers, no more manually freeing memory and no more buffer overflows.
  • Use verification tools — impose constraints that will make verifications easier.
  • Improve system architecture and design.

Singularity Architecture

Microsoft Overview of the Singularity Project

Singularity provides 3 main abstractions:

  • Software-isolated processes (SIPs)
  • Contract-based channels
  • Manifest-based programs (MBPs)

Let’s drill down into each of these.

Software-isolated processes

A SIP is just like an ordinary process — holding the processing resources, context, and a container of threads.

The quite surprising part is that all SIPs and the kernel are running in the same address space which also means user code runs with full hardware privileges.

Isn’t it totally counter-intuitive? we just mentioned that we want to improve security as one of our goals and this change seems to make it worse.

First, let’s think about why would they even make this change

Does it improve anything?

The answer is yes (obviously), it improves performance.

Since all SIPs are in the same address space, context switches are performed faster

  • No need to switch page tables
  • No need to invalidate and repopulate TLBs

Moreover, system calls are also faster

  • We are always in CPL=0
  • No need to load the kernel stack
  • Instead of sending an interrupt, we can just call a function
Microsoft Overview of the Singularity Project

After we convinced ourselves that with this change performance is better let’s take care of the seeming security problem.

Each SIP is actually sealed — They can’t be modified from outside.
There’s no shared memory between different SIPs, no signals, only explicit IPC.
There are also no code modifications from within — no JIT, class loaders, dynamic libraries.

To ensure that SIPs are actually sealed we employ the following constraints

  • A SIP only points to its own data — no pointers to other SIPs
  • No pointers into the kernel
  • SIP exclusively accesses memory the kernel has given to it
  • SIP cannot create new pointers — pointers can be provided from a trusted source such as the kernel.

With these constraints, although there is a shared address space, there is no sharing of data.

Contract-based channels

We can think of channels as capabilities.
Each SIP can have multiple channels that through them we can create IPC(inter-process communication).
For Example, an open file is a channel received from the file server.
If a SIP gets this channel it means that it has permission to access it.

Manifest-based programs

A manifest describes the capabilities, required resources, and dependencies of a SIP.
A SIP can’t do anything without a manifest and channels.
When installing a manifest we are verifying that it meets all safety requirements, that all of its dependencies are met and it doesn’t create a conflict with a previously installed manifest.
For example, a manifest of a driver provides “evidence” to prove that it won’t access the hardware of another driver.

Before we part ways, here are some more figures and tables illustrating a comparison between Singularity and other well known operating systems

Conclusion

Singularity is just one example out of many experimental operating systems.
Its last release was in November 2008 and since then the project was stopped.

You can find the source code on Github.
If you want to read more about this topic here are some good materials


If you are looking to get more familiar with operating systems I can advise on the following materials/books

References

[1] Microsoft Overview of the Singularity Project

7 comments on “Singularity – Microsoft’s Experimental OS

  1. What an exquisite article! Your post is very helpful right now. Thank you for sharing this informative one.

    Liked by 1 person

  2. Interesting topic and great post! I wonder why they didn’t continue with that idea for an alternative windows release, maybe because of compatibility with prior/current software? Or maybe they introduced some of the ideas in their subsequent releases?

    Like

  3. Pingback: Microsoft's Experimental OS – Singularity - The web development company

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: