Singularity III: Revenge of the SIP
- Posted: Aug 18, 2006 at 2:16 PM
- 94,406 Views
- 41 Comments
Download
How do I download the videos?
- To download, right click the file type you would like and pick “Save target as…” or “Save link as…”
Why should I download videos from Channel9?
- It's an easy way to save the videos you like locally.
- You can save the videos in order to watch them offline.
- If all you want is to hear the audio, you can download the MP3!
Which version should I choose?
- If you want to view the video on your PC, Xbox or Media Center, download the High Quality WMV file (this is the highest quality version we have available).
- If you'd like a lower bitrate version, to reduce the download time or cost, then choose the Medium Quality WMV file.
- If you have a Zune, WP7, iPhone, iPad, or iPod device, choose the low or medium MP4 file.
- If you just want to hear the audio of the video, choose the MP3 file.
Right click “Save as…”
- Mid Quality WMV (Lo-band, Mobile)
- WMV (WMV Video)
It's been a while since we checked in with the Singularity folks over in MSR Redmond. You know, the usual suspects like Jim Larus and Galen Hunt. So, Charles went and visited them recently to see where they are with Singularity, see what they're up to,
what's new... As you may expect, they are doing some really interesting work with, among other novel software constructs, SIPs (Software Isolated Processes). Learn all about them and how they are architected into the Singularity system. Yes, we get Galen on
the whiteboard again. This time, you will also meet the newest member of the Singularity team, Mark Aiken, Software Developer, who's been working on some interesting hardware protection stuff in Singularity. It's always great to spend time with the Singularity folks. Oh
yeah, this time we get a demo of Singularity.
Comments Closed
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation,
please create a new thread in our Forums,
or
Contact Us and let us know.
Follow the Discussion
Rebuilt my computer today and I ahve been trying to will myself to plug in speakers, you have finally give me a decent reason to do this.
Best (hopefully) channel9 video in a long time, can't wait to watch it.
Kevin
Edit:
OK, just finished watching it, absolutely excellent video, didn't disappoint. Definitely one of the most exciting projects in Microsoft at the minute. Also cool to see that the team are working with the likes of Tony Hoare, definitely gives it some serious credibility in my opinion, not that the team isn't credible as it is...
Just one thing, where is the demo? Did you guys not get a chance to do that, or are you just waiting for that tape to be encoded etc.?
btw, you can get the paper on process isolation right here. checking out the other papers available on the singularity project's website is really worth the time.
Thanks again for the video!
A few questions:
Is Singularity a lot slower then traditional operating systems once hardware protection is activated?
How do you make sure that a pointer does not point to any address space of another process? Are there no classes in your C# dialect that allows that? Is there no IntPtr class and therefore no way to initialize a pointer with an int?
I don't think their safe language (SPEC#) allows that. From the video, the way it works seems to be that a process can only use the memory pages that are supplied to it by the kernel, therefore it is up to the kernel not to supply to SIP's with memory thatcould be shared.
I think this is the reason for the hardware protection boundary, if there is an error in the kernel code etc, which is very unlikely, then the hardware protection can kick in and prevent processes from destroying each others data.
Again, that is just what I picked up from the 3 videos.
Kevin
I don't think a CTP would be much fun, unless of course they supplied the source code with it, and I think the chances of that are (understandably) zero.
Pity
Kevin
That could it be... But it would be great, if one of the guys (from the team) could provide a few informations on this.
Yeah, hopefully after the weekend they come on and answer some questions, I remember after the last videos they were quite active in the forums.
Kevin
Them having an IntPtr type isn't a problem. IntPtr is just an int with the size of a pointer, it's not actually a pointer. It's when you can use that number as if it were a pointer that you get in trouble.
In the traditional CLR, there are only two ways you can use that IntPtr as a real pointer. The first is to use unsafe code and actually cast it to an unsafe pointer. They explicitly state in the video they don't allow that. The other way is to use the System.Runtime.InteropServices.Marshal class. Since the methods of this class are inherently unsafe I would guess this class, nor any alternatives, exist in the runtime used on Singularity.
You think they only don't provide the possibility (by not having the classes or methods) or they also check it? I'm wondering if they provide also checks in the runtime (that is part of each process) or if they only don't provide the classes to do native pointers.
Is Singularity a lot slower then traditional operating systems once hardware protection is activated?
Probably not -- it is a bit hard to answer the question phrased this way, since you are asking for an apples to oranges comparison.
Let me explain.
We have measured Singularity with varying levels of hardware protection enabled. (Details in Deconstructing Process Isolation, Mark Aiken, Manuel Fähndrich, Chris Hawblitzel, Galen Hunt, James Larus, Microsoft Research Technical Report MSR-TR-2006-43)
The results depended a lot on what was running on Singularity. A computationally intensive application wasn't affected by adding hardware protection, since it ran in one process, didn't thrash the TLB, and did little communication.
An IO intensive application ran a lot (~30%) slower with hardware isolation, since it required frequent context switches and a large amount of interprocess communication, both of which became a lot more expensive with hardware protection.
It would be interesting to compare these numbers against another system, but there are so many differences that it would be difficult to isolate the cost of SIPs and hardware domains vs. conventional processes. Instead, we've modelled a conventional systems as a version of Singularity in which the kernel and device drivers run in one hardware domain and application and system processes each run in their own domain. There is a considerable cost for this arrangement for the IO intensive benchmark.
The other interesting result from this paper was that turning off run-time checks for null pointers and array bounds only saved 4.5%. Language safety isn't necessarily expensive when you have a good compiler.
How do you make sure that a pointer does not point to any address space of another process? Are there no classes in your C# dialect that allows that? Is there no IntPtr class and therefore no way to initialize a pointer with an int?
We rely on two aspects of the system design.
First, application and system code (aside from the kernel and run-time system) is written in safe C#. In this language, like Java, you can't create a pointer and you can't mangle a pointer. Period. This is a property that a compiler (and some run-time tests) can check, and we do.
We're working on reducing the amount of code that is unsafe. It is an interesting set of open research problems (i.e., what would a safe, verified garbage collector look like?), but we don't have answers yet. Stay tuned.
The other property is that a process cannot pass a pointer from its space to any other process (or the kernel). The channels do not allow code to pass addresses (we check in the compiler) and the kernel interfaces do not allow pointer passing either. This has a lot of benefits in a garbage collected system as well, since we don't have to look for root pointers in other processes.
So, if a process can't create a pointer and it can't be passed a pointer, there is no way for the process to dereference another SIP's objects.
Is there an MSR team researching how to upgrad and OS over many interations ...
This is a problem we (Singularity) are very interested in. It is not an easy problem for any piece of software, particularity a platform on which other software is built, particularly a widely successful platform.
There are a couple of things we've done already and a few more that we're thinking about.
First, our interfaces are strongly versioned. You compile against version 1.1.1 of the kernel API or library interface. We can tell what version code was compiled against, which makes it a lot easier to produce shims and backward compatibility layers.
Second, applications are described by a manifest, which specifies all of the components of the application and all of the dependencies among them. The system owns the application abstraction and controls the installation process. We've designed it so that the system can read the manifest and determine if installing the application would cause any conflicts -- before a single file is installed. If there are conflicts, the system can refuse to install a new component (ie device driver) or application.
Third, channel provide a very well defined interface between parts of the system. They have an explicit communictaion protocol (which we check) and the communications patterns are well defined (and can be constrained by the system, another story). This helps keep the system structure organized and gives us a way of making and enforcing policies (i.e., device drivers only have two channels: one to establish a connection and one for control).
We hope that these ideas will help keep the system well structured as it evolves, but only time will tell. Right now, Singularity is a small system (a few hundred thousand lines of code), and the real challenge would only arise if it grew and was maintained by a larger, less cohesive team.
Yes (unfortunately). Parallel programming is hard, but no one has any other idea of how to keep making processors faster.
Hi Laurus. Thanks for the answers.
I asked the first question, as one of you three (it could have been you, I don't remember the name, I'm sorry) mentioned a bunch of numbers on hardware protection.
I know that comparison is hard, since your concept of hardware isolation is a little bit different then the traditional way to do it. I was just curious, because somebody mentioned in one of the last videos that singularity is x% faster then Windows (or other OSes), because of no context switches etc.
The second answer is quite interesting, as some of the check can only be done as you compile the code once it is loaded and since you have just one compiler doing the work. I mean if somebody would create a second compiler you would have problems, wouldn't you?
That is another question that came to my mind: is it possible to write a compiler for Singularity that creates code that could do everything? With everything I mean everything in it's own process (creating pointers, load code from address x): i know that you said that channels don't allow pointers being passed to another process. Or isn't it possible because that compiler would have been loaded and compiled by your own compiler and that one wouldn't allow it... I guess the second option is the right one, isn't it?
Thanks again.
It's great to see that somebody just creates a fresh new OS, thinking ahead! I know that we won't see Singularity in the public for a while (will we ever see it?), but it's just great, to see that something is happening.
Have you ever thought of emulating the old OS inside Singularity?
Since Singularity won't reach a mature state (mature = can be used by a lot people, without going back to the DOS UI and knowing much about OS internals) in the next couple of years, emulation could be an interesting alternative.
Do you guys envisage running into similar perf issues that they did with OSX, which is also based on a microkernel?
I don't think so. The performance problem associated with a traditional microkernel come from the fact that all the drivers and stuff run in separate processes which have a separate address space and possibly also run on a different CPU ring, so you have to do a context switch when transitioning to/from the kernel and these drivers etc.
As they showed in the video, Singularity can still achieve isolation without having to put all the parts in different address spaces, so they can avoid the perf hit from the context switch.
Do you mean an interpreter for a language like Perl or Python? We've thought about this (but haven't done it yet). At one level, it is very easy. We can write a pure (CS101) interpreter that accepts a program as a text string and executes it. That would be slower than modern interpreters that compile a program to executable code, so the next stage is to include a code generator in the interpreter. As long as the code generator is part of the trusted computing base (ie Singularity), there is not fundamental problem with this approach. An interesting research challenge is to verify the code generator, so that it doesn't need to be trusted. This is a fun area to think about, with lots of good open problems.
Since Singularity won't reach a mature state (mature = can be used by a lot people, without going back to the DOS UI and knowing much about OS internals) in the next couple of years, emulation could be an interesting alternative.
No. Seriously. We decided at the beginning that we wouldn't worry about backward compatibility. After all, we're not writing a commercial OS or building the replacement for Windows.
So far, we haven't regretted this decision. It has allowed us to look at more interesting ways of doing things and not spend a lot of time trying to figure out how to run "dusty decks".
We're pretty confident that we will not run into the same performance issues as Mach, OSX, or other microkernel OS. Those systems relied on hardware mechanisms to protect the kernel against user code and to keep one process from messing with another. They had no choice, since those systems were written in C, and so got absolutely no support on the programming language side.
Our TR ("Deconstructing Process Isolation" -- on the Singularity web site) contains some measurements of the cost of using a processor's virtual memory hardware and protection rings to provide isolation. The cost can be high, both in performance and in system complexity. In addition, it becomes a lot harder to pass information between processes when they live in seperate address spaces, so you start taking short cuts like sharing parts of the address spaces.
SIPs reduce the cost of process isolation and communication. In one sense, they shift the checking necessary to provide isolation from run time to compile time. This is a great tradeoff, when you can take advantage of it. It also demonstrates that software schemes, when properly architected, can be faster than hardware assisted approaches. (For another interesting example, find a copy of VMWare's forthcomming ASPLOS paper "A Comparison of Software and Hardware Techniques for x86 Virtualization" -- they found that sofware VMs could run faster than VMs that used the new virtualization features in x86 processors.)
When I first heard about channels, I thought that they would be slow (copying data). I did not think of having the kernel reassign ownership of memory pages to other processes. Is that what is happening? Screw shared memory!
-Josh
Ever since I started writing in the .net clr, I knew this kind of complete definition of language and structure to programming and (by extension) complete management of the OS was the sound way to go.
Pretty sure I understand the weaknesses of NT, essentially being that; if the world was perfect and we didn't have nasty people, we didn't write 'faulty' code, and hardware never failed, NT would be perfect. But we don't- and we DO need complete management of the OS. I guess more of a 'Ok, here are the rules.' instead of 'Go crazy and do what you want, oh but don't do that... or that... no not that either, oh god stop doing that!'.
Microsoft obviously must see this too, the current environment of Windows is just too complex to manage, and I guess Microsoft spend far too much time actually welding bits onto Windows in order to try and constrain the OS to how they want it.
Saying all that though, while this kernel has me very excited, theres a big aspect of "I will probably never see this as a general Windows kernel", and that NT may be 'inspired' by some of the structure of this, but nothing more...
As much as I love NT and Windows, I think its a remenant of past thought, and like .NET and other recent work by Microsoft, this kernel concept is the future...
I just hope they realise it... [C]
But, IIRC, they said when you pass a message over a channel between SIPs, one of the reasons it is fast is because it is a reference to the object and not a copy. So the other SIP has a pointer to the data. Is this not correct?
BTW - another great video guys!
Secondly, I have a question. I was going through the paper TR-2006-43.pdf where it is mentioned that unrelated processes could have hardware barriers between them, whereas processes that share data may not have hardware barriers.
Isn't the situation similar, if not entirely, to the way things are today? unrelated processes do not share data or data are copied between them; on the other hand, application servers are a single process where all applications are within the same address space.
So my question is: is it worthwhile to turn the whole concept into a separate O/S built from scratch? would it not make more sense to use the knowledge gained by the singularity project to built a programming language with the advanced safety features of singularity as well as an application server which would host such processes?
I am aware that the singularity project goes beyond processes all the way down to the kernel. But maybe the singularity application server could offer 'drivers' and 'kernel' support to the singularity modules, i.e. the application server could be a virtualization environment even for the hardware.
The reason is that there is already much running code out there, and it would be shame to 'dump it all'.
Would it be posible, if you were on a mission to break Singularity, to write a compiler that did not implement all the compile time checks thus allowing you access to pointers and the like, or is all code fully verified at runtime as well?
Yes, in most cases, we pass a pointer rather than copy data. This does not result in shared memory, since we also make sure that the process sending the message does not retain a pointer to the data. This is the result of a programming language property called linearity that our compiler enforces on data sent acrosss channels.
There are cases where we do copy data. They arise when a system uses hardware domains to put SIPS into separate address spaces. Then, a message needs to be copied from one address space into another, which makes communication more expensive and makes hardware isolation more expensive than SIPS.
The nice thing about linearity is that a program can't tell the difference between the two cases, so we can optimize the implementation.
Lots more details on this in our paper:
Language Support for Fast and Reliable Message-based Communication in the Singularity OS, Manuel Fähndrich, Mark Aiken, Chris Hawblitzel, Orion Hodson, Galen Hunt, James Larus, and Steven Levi, EuroSys 2006 Conference, pp. 177–190.
Isn't the situation similar, if not entirely, to the way things are today? unrelated processes do not share data or data are copied between them; on the other hand, application servers are a single process where all applications are within the same address space.
So my question is: is it worthwhile to turn the whole concept into a separate O/S built from scratch? would it not make more sense to use the knowledge gained by the singularity project to built a programming language with the advanced safety features of singularity as well as an application server which would host such processes?
There are lots of ways in which the ideas from Singularity can be applied. We deliberately took some extreme positions (message passing, no dynamic code loading, safe languages, etc.) and tried to see where this architecture would go. As with most research, some of the ideas will have more impact than others, but it is hard to know in advance what they will be.
Yes. But, we're working to fix this hole.
Right now, rightly or wrongly, we trust our compiler to ensure type and memory safety. It isn't a good idea, since our compiler is a complex, optimizing compiler that still has bugs (as do all compilers).
And, practically, we can't use another compiler, since we would have no reason to trust it.
However, we're working hard to apply an idea called Typed Assembly Language (TAL) to fix this hole. TAL requires that a compiler produce a proof of the type and memory safety of the code it compilers, along with the x86 instructions (it isn't a big deal for a compiler for a type safe language, as it just has to propagate this information through all its phases). A proof isn't large and it is easy to check against the x86 code. The checker is a couple thousand lines of code, which can be very carefully written and incorporated into Singularity. With TAL, any compiler that produces a proof is usable for Singularity and we do not need to trust any (including our) compiler.
Here's a reference to TAL
Morrisett, G., Walker, D., Crary, K. and Glew, N. From System F to Typed Assembly Language. ACM Transactions on Programming Languages and Systems, 21 (3), 1999, 527-568.
Fantasitic program - I have loved all 3 now. I would like to get the research paper mentioned at the end of the program - where can I find it.
Best wishes
Chris Kelly
All our papers, techincal reports, etc. are on line:
http://research.microsoft.com/os/singularity/
Enjoy!
1. What do the runtimes of the individual applications contain except the garbage collector?
2. Are you going to release the executables and/or the source code of Singularity and/or the tools (Bartok, sing#)?
Obviously, Singularity is very new, implemented in a radically different fashion from traditional OS' using languages and dev tools that are wayyy out there on the bleeding edge! However, despite this, comparing, for example a system the access a bunch of data on disk, processes it and exchanges it between worker processes, Singularity actually turns in perf numbers that are typically *very* close to the perf of XP or Linux! There are several scenarios, in fact, where Singularity wipes the floor with ANY other OS!
Don't forget, a typical user-mode <--> kernel transition is not cheap! This is why GDI, for example, batches up calls to the graphics driver rather than crossing the boundary every time something on the screen needs to be updated. Singularity gets to replace the CPU ticks lost during transitions with CPU ticks that actually do work like making sure that the software is running correctly.
Spec# (derived from C#) is, like most managed languages, doesn't have a notion of pointers (as traditional C programmers would recognize them). SIP's (Software Isolated Processes) can't reach beyond their own boundaries, just like one Win32 process can't reach into the address space of another Win32 process.
Some days when I get down, I go and browse the Singularity source. The sheer beauty of this thing just cannot be overstated. Once you've seen a graphics driver or filesystem written in pure C# that exposes a hard contract which defines how callers MUST call it (whch cannot even be compiled unless they conform to the graphics driver SIP's contract). I've often been reduced close to tears looking at this thing - it's just jaw-droppingly beautiful!
Hi everyone,
I hope this thread is still active.
I have read the above mentioned paper and I got some questions about it:
1. In the example with the methods Consume(vec) and Reverse(vec) you mentioned that it would result into an access error if Consume(vec) happens before Reverse(vec), which is clear since after the execution of method Consume(vec) the tracked vector is no longer available for Reverse(vec).
But: Is the compiler still able to verify the following code?
if(...) {
Consume(vec);
}
Reverse(vec);
or
if(x > 0) {
Consume(vec);
} else {
Reverse(vec);
}
if(x <= 0) {
Consume(vec);
}
The first example is only safe, when the if branch isn't executed.
The second example is actually type safe, but according to the paper "Enforcing High-Level Protocols in Low-Level Software" by Robert DeLine and Manuel Fähndrich the type checker will reject it. I think the verification main idea is actually the same in Sing# as in Vault.
In Vault's type system the programmer has to use keyed variants to fix this problem? How is this done in Sing#?
2. In the paper you mentioned that Channels on Singularity outperform the mechanismns available in Windows/Linux/FreeBSD by the factor of 4 to 5. You also state that this improvements don't even factor in the ability to pass pointers rather than copies of memory blocks. So, from what does this result from? Does it have to do with the expensive system calls in the other systems?
Remove this comment
Remove this thread
close