Microsoft has released new details on an experimental operating system concept named Drawbridge. In early March Microsoft researchers presented a paper entitled Rethinking the Library OS from the Top Down. The paper describes a new interaction between a user-level application and its OS. The paper can be found at the ACM Digital Library [frustratingly, we can’t redistribute the article since it’s behind a paywall, like too much of the scientific world]. It describes an ambitious plan to separate the traditional API parts of an OS from the underlying kernel of the OS. But a full analysis requires some background.
In 2007 Eric Traut, a developer at Microsoft, revealed a new kernel under development called MinWin. This new kernel was the same NT kernel that had been around since Windows NT 3.1, but it was refactored to be a more modular, smaller kernel. The result was a kernel that had a memory footprint of about 33 MB that could be used to build future versions of Windows. MinWin went on to be used in Windows 7 and Windows Server 2008.
Many people were wondering if MinWin would be released as a separate product. In the past, Microsoft has taken the ^aEURoeMonolithic^aEUR part of the monolithic operating system to its extremes. If there were a tight, lightweight kernel underneath all that bloat it would represent some exciting possibilities. What everyone was forgetting is MinWin did not represent the creation of one thing but three. MinWin was at the bottom, the top was all the Win32 ^aEURoeguts^aEUR applications used to access the OS, but the interface between MinWin and the Win32 API was a triumph in and of itself. MinWin could be replaced by more advanced technology, but as long as the interface stayed the same the upper layers would continue to function correctly.
Fast forward to Drawbridge and we find that Microsoft has taken advantage of this modularity. Drawbridge can take a user application, for instance Excel 2010, and then package it with the parts of Windows 7 that directly interact with that application. Drawbridge then creates a package with these two elements and calls it a library OS. The library OS uses a highly simplified Application Binary Interface (ABI) to interact with the underlying OS. There are over 100,000 API functions within Windows 7. These are all consolidated into a black-box that is merged into the Excel process making one modular package. Currently this works for Windows 7 applications (or apps that can be run on Windows 7.
Drawbridge Advantages
There are a number of immediate advantages to packaging parts of the OS into the application. The Windows registry can be virtualized into a private store for the one particular app. Although not mentioned, one side effect of registry virtualization should be when the app is removed it should clear out all application settings. So there would no longer be anything left behind.
Because much of the state of the OS is contained within the package, the app could more easily be migrated from one running machine to another. The app is paused and a snapshot of its memory is taken to migrate it to another machine. This snapshot can be as little as a few megabytes. In contrast, a snapshot of a full-blown OS guest partition under Hyper-V or VMware is many times larger.
The Drawbridge paper details a number of security advantages as well. With the OS API virtualized into each application package, it’s harder for one app to compromise the configuration of another app. The need to apply security patches is also greatly reduced; a library OS package is not a fully blown OS, therefore, its attack surface is greatly reduced so there are fewer vulnerabilities.
Underpinnings
But what is the underlying OS that runs this package? The Drawbridge paper details their work with no less than five operating systems that have been redesigned to run Drawbridge packages:
- Windows 7. For those who think running a Windows 7 application on Windows 7 is not all that groundbreaking, remember Microsoft is trying to demonstrate portability across multiple operating systems. What better place to start than with your current desktop operating system. Remember also all the other benefits of a Drawbridge package.
- Windows Server 2008 R2. Similar to Windows 7, the server platform must be supported to provide for a smooth transition.
- Windows 8. The Drawbridge paper doesn’t call it ^aEURoeWindows 8^aEUR, they simply name it the ^aEURoepre-release of the next version of Windows^aEUR. No surprise here as it can be assumed Windows 8 will be at least as capable as Windows 7.
- MinWin. Here’s where it gets interesting. If most of the OS functionality is packaged into the application, why deploy onto a full version of Windows 7? MinWin fits the bill quite nicely and fulfills the promise of a lighter, more agile Windows operating system.
- Hyper-V. The Drawbridge package runs at Ring 0 while the hypervisor continues to run at Ring -1. This might be useful for virtualizing user applications while imposing less overhead than a traditional guest partition with a full OS.
- Barrelfish. A separate team of researchers have started, but not finished, an implementation of Drawbridge on Barrelfish. This is a research OS under development. It was started from scratch to explore operating system concepts for scaling across hundreds of CPU cores. Barrelfish is some awesome technology that rethinks many OS concepts from scratch. If it could be modified to run Drawbridge apps it would gain a huge library of existing software. Drawbridge could help a research OS like Barrelfish come to market more quickly.
Speculation on Future Work
Although Microsoft could port non-Windows 7 applications to the Drawbridge platform, it seems unlikely they would expend such efforts. How many apps run fine on Vista but not Windows 7? Very few fall into this category. A more likely target would be Windows XP, but Microsoft has expressed little interest in supporting an OS whose support officially ended in 2010.
Microsoft could port applications from other OSs to run on a Drawbridge platform. The design is modular; the interface has a fixed application binary interface (ABI) where the app interacts with the OS. An emulation layer converts all the native operations, e.g. accessing memory, disk, network, etc., to a fixed language that can then call the underlying operating system.
Future endeavors will likely be directed towards keeping Windows 7 as the application framework and instead completely ripping out the guts underneath. We already see these efforts with MinWin and Hyper-V. In the extreme, these efforts lead to platforms like Barrelfish, where the OS and kernel are completely legacy-free.
One of the co-authors on the Drawbridge paper is Galen Hunt, who is one of the primary researchers on the Singularity project. Singularity is a complete reexamination of the OS paradigm. It was written as a memory-safe and type-safe OS and has zero backwards compatibility with any existing software or drivers. If it could run existing user software using a facility similar to Drawbridge it could bring Singularity out of academia and into production. Midori is a rumored incubation project that is based on Singularity. Its Achilles heal has been its lack of support for the existing base of software in the world. Drawbridge could bridge this gap.
Microsoft’s Future
Back in the late 80’s Microsoft had a problem. Applications, drivers and utilities needed access to more memory than 640kB. The industry was starting a painful transition to 32-bit operating systems and Microsoft was behind the competition. Competitors like OS/2 were positioned to eat Microsoft’s lunch. Through Windows for Workgroups 3.11 and Windows 95 Microsoft was able to catch up and offer a 32-bit platform with backward compatibility with existing MS-DOS and Windows application. That hat-trick cemented Microsoft’s dominance in desktop computing for twenty years.
Microsoft now faces a different problem. The industry’s transition to 64-bit is nearly complete and with much less pain than its 32-bit transition. The problems now stem from more fundamental OS concepts. The monolithic nature of Windows manifests itself mostly in its security, or lack thereof. New security patches are exactly that, patches onto a giant system that is proving itself increasingly fragile. The underlying problem is the lack of modularity in its core and the inability of Windows to evolve. Many foundational OS concepts cannot be changed because they would break compatibility; hence the need for more patches. If Drawbridge enables rapid innovation in the core of the OS, Microsoft may be able to dodge its fate a second time.
Every time I have emailed the authors at MS about paywalls they have put the article up on an MS server and sent me a link in a day or two.
That holds true for almost any publication you can find out there. I’ve done this, both ways – ask for and send out publications – multiple times, just go directly to the authors.
Could someone ask for it ? browsing the source article sounds very interesting.
This is terrible. Look at the benefits – cleaner exits of applications, security. Instead of creating a simpler more elegant design they go the opposite direction and create a crazy monster solution… only Microsoft could make a virtue out of this.
How is it terrible? If you create an application and compile it into the said package then a future release Microsoft can make some radical changes and not have to worry about backwards compatibility. For example in Windows 8 they could make some major changes to the operating system such as removing old crufty APIs etc. and old applications using the packaging system would continue working without any problems.
It appears that Microsoft is moving towards a three tier model of backwards compatibility; virtualisation (hosting a complete operating system), the packaging model in said article and then native applications. As part of this packaging will it also include ARM/x86/x64 binaries all in one package? that would be a great feature if they not only provided the above packaging for compatibility but multiple binaries as well.
meaty article
If it’s behind a pay wall then it’s to embarrassing to release to the world.
Microsoft’s pushing the envelope. There have been some other entries in this field, including IBM i, which does a very effective job of decoupling applications from the kernel (but also goes farther than Microsoft — the binaries automatically recompile to take advantage of hardware changes), and Oracle VM, which is a “no OS” appliance designed to run WebLogic.
This approach seems very appropriate for the virtualization/cloud wave we’re on now.
Just to be clear, MinWin is not nor has ever been a new kernel. MinWin is a collection of the pieces at the lowest layers of Windows built in a standalone way. It is an attempt to enforce layering in the system – lower layers should not depend on upper layers to operate. WinWin should be thought of as a GUI-less subset of WinPE, which is (roughly) a subset of Server Core, which is a subset of fully fledged Windows. The kernel is the same in each.
The comments at the end of the article about security seem misguided about what the impact of the approach presented really is. If each application contains its own isolated usermode environment and talks to the kernel directly, the consequence will be more patching. If a bug is found in those layers, it needs to be patched in every application, as opposed to patched once in the OS. If an application is not being actively serviced, the user can be left more exposed to exploits rather than less. Not to mention the less efficient use of disk space, memory, etc.
The main benefit here, IMO, is allowing each application developer to test and deploy software in a tightly defined environment, to minimize the chances of an application misbehaving when deployed to the millions of random Windows installations out there.
From what I understand though this ‘WinMin’ was only the start of a much larger project. The scope of the project is beyond just focusing on the lower levels to also include modularising the whole operating system to avoid the spaghetti of dependencies. The basic idea then is that a small group can work on particular module in isolation, make changes then merge back into the larger tree without all hell breaking loose. The result of that are changes can be made and the amount of regressions should substantially reduced thus the compatibility within the OS and third parties should be maintained relatively easily.
The security therefore is up to the application developer to provide updates for their applications by recompiling against operating system updates that Microsoft releases; thus there is more burden on the third party developer in terms of providing regular updates but at the same time there is a lot more power at his disposal in terms fine grain testing against a very specific version of Windows of a particular build/service pack. The result is that enterprise customers can release updates promptly and not have to worry about any disruption caused to issues between said updates and third party applications installed. The result is that the operating system is secure and you as a third party can control the environment that your applications are going to run in.
The other side of the equation regarding alternative operating systems, could we see Microsoft maybe scrap Office for Mac in the future in favour of a single release of Microsoft Office that includes the said abstraction layer which is bundled with Office for Mac thus not having to maintain two versions etc. Could we see maybe see Windows 8 and Windows CE offered on the tablet to OEM’s and Microsoft using said packaging system to offer their applications on both platforms? Interesting times ahead if these academic ideas are transformed into real products.
Edited 2011-05-05 03:22 UTC
You^aEURTMre totally right. Having a subset of the OS packaged into the application means with 50 Drawbridge applications installed on one system you would have to potentially patch 50 OS sub-systems. Nightmare.
Thankfully, it probably will not be that bad.
1. Vulnerabilities exposed in an app should not be reachable if the app is not running. The attack surface is limited to those apps that are actually executing.
2. Patching all those Win32 subsystems will hopefully be automated with tools.
3. If a particular app doesn^aEURTMt need 98% of the OS subsystem, those unused parts could be pruned off prior to distributing it to the end-users. Would this be something the developer could do or would it take a team of engineers familiar with the underlying guts of the OS to pull off? I don^aEURTMt know. Hopefully the former (with automated tools).
4. Remember, this is only a stopgap solution. The real goal is to roll out an entirely new OS that is MUCH more secure (among other tangible benefits, I^aEURTMm sure). Drawbridge could then be used to supply backward compatibility during a transition period (i.e. 20 years). During that time, our core OS would be much more secure but our Drawbridge apps would be no better off, but no worse off.
Edited 2011-05-06 11:37 UTC
Zones Containers and Jails. Are all from the Unix world.
Issue for the Unix world has been X11 itself. Wayland is working on solving the last splitting issue.
So really this move is nothing more than trying to catch up to competition.
I guess you might be young. Many mainframes already had such features, and Unix was still a to be born OS.
Edited 2011-05-05 08:42 UTC
I really liked this article and it felt short which is always good. It also gives me hope for ms
This looks like packaging the Wine libraries with the application program.
If the run-time system calls are so much reduced, then running Win applications on Linux is going to be far more simple !
Actually it reminds me of wine with prefixes. Maybe WineHQ should sue MicroSoft.
If you can read French there is some technical information available here
http://www.blog.ma-config.com/
I’m pretty sure we can all read it… It’s the understanding of it that we’d have trouble with </smartass>
All of this looks to be a copy of chroot() and winebottler from unix systems…
MS playing catch-up and trying to market it as something new, as always.
And Unix plays catch up with Mainframe systems.
chroot is flawed.
Zones Containers and Jails. Are the latter techs. Some people think these are mainframe pre Unix. Infact they are after Unix.
Pre Unix was the precursor to virtualization.
But yes. Been done for years in the Unix world. Only thing anywhere near exciting is that it up into graphical.
DRI2 Wayland alterations allow same kind of features with Unix based containment. Virtual interfaces for sound from cgroups from linux, Jails from bsd and Zones from solaris already exist.
I would also think this would help create an iOS-like version of Windows. Windows would scale better to the small world. If they follow this same modularity concept with Office apps, they could create mobile versions of Office apps that are fully-compatible compatible with a more mobile interface.
As an example, the base OS could be Phone 7, but a specially-packaged version of Word with Drawbridge would bring a fully-functional version to tablets, instead of the current “mini” apps.
Sounds a lot like The OS Project’s API Converters (http://theosproject.sourceforge.net/Requirements/api_converters.htm…) applied slightly differently. The main difference is that MS is pushing the converter into the application where TOSP wanted to run one converter for all applications using that API.
Refactoring an existing OS to a library OS and using it as a virtual machine substitute sounds a lot like RUMP on NetBSD which according to the man page was present already in NetBSD 5.0:
http://netbsd.gw.com/cgi-bin/man-cgi?rump++NetBSD-current
Hi,
I’m having trouble seeing any point to this. To avoid excess bloat, the first thing application developers would do is use the “Drawbridge API” instead of the (legacy) Windows APIs.
Then, in 10 years time (after Microsoft has created 5 different versions of the “Drawbridge API”, each more bloated than the last), some smart-ass will come up with a way of switching to a newer/leaner API and implementing the “Drawbridge API” in a library.
Then, 10 year after that…
– Brendan
I am not fluent C or low level coder, but can anyone help me to understand, by answering following two questions?
1) Isn’t packaging OS API into each application kind of waste of resources? And what if that layer has a bug? All such apps will have to be patched?
2) Hmm, app local registry – does not it contradict the initial purpose of registry = having everything in one place? How does it differ then from the plain text, local app config files?
I have to be missing something. I know that such isolation might help them to migrate between various kernels, they solve it in kind of “app virtualisation” manner, but imo it is still significant waste of resources.
Just my two uneducated cents …
I wasn’t sure how to read that as well. I am not sure it means having a separate registry database… It might just mean that the registry would be organized differently?
It means, just like the article says, that when you uninstall an app, there won’t be any leftover cruft hanging around in the registry.
The registry is just as much about having a standard API for storing settings as for having all in one place. Most settings are application specific anyway. I guess there are a few settings that affect all apps, though. I’ll admit that having multiple instances of those does sound like a problem.
Re: API, yes, a good thing. I was just wondering if they meant separate files per application or reorganizing the way entries are written to the [one] registry so that application separation is not buried as deeply as it is now and there are no cross-referenced values, stuff like that.
I read this as meaning the registry is stored inside the application package.
Yes, now that you mention it, that does seem obvious.