Linked by Dan Massameno on Wed 4th May 2011 21:28 UTC
Microsoft 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.
Thread beginning with comment 471836
To read all comments associated with this story, please click here.
MinWin
by malxau on Thu 5th May 2011 00:19 UTC
malxau
Member since:
2005-12-04

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.

Reply Score: 2

RE: MinWin
by kaiwai on Thu 5th May 2011 03:18 in reply to "MinWin"
kaiwai Member since:
2005-07-06

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.


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 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.


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

Reply Parent Score: 2

Patching will hopefully not be that bad.
by danmassa7 on Fri 6th May 2011 11:35 in reply to "MinWin"
danmassa7 Member since:
2008-07-22

You’re 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’t 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’t 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’m 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

Reply Parent Score: 2