"Midori" Concepts Materialize In .NET

dp619 writes "Concepts outlined in Microsoft's internal 'Midori' OS documents are materializing in .NET, according to an SD Times report. Midori is a new operating system project that is designed for distributed concurrency. Microsoft has assigned some of its all-star programmers to the project, while recruiting others. It is also working on other projects to replace Windows that make the OS act more like a hypervisor."

Re:Hypervisor

[sopssa]

What are you smoking? Windows kernel itself hasn't really been vulnerable to anything, it's the third party software like Flash, Adobe PDF Reader, internet browsers, and previously some services.

Re:Hypervisor

[Anonymous Coward]

It may as well be.

Re:Hypervisor

[Jahava]

What are you smoking? Windows kernel itself hasn't really been vulnerable to anything, it's the third party software like Flash, Adobe PDF Reader, internet browsers, and previously some services.

So here's what Google [google.com] has to say on the subject:

• Vulnerabilities in Windows Kernel [energy.gov]
• Vulnerabilities in Windows Kernel Could Allow Elevation of Privilege (977165) [microsoft.com]
• Vulnerability in Windows Kernel Privilege Escalation [vistaheads.com]
• GDT and LDT in Windows kernel vulnerability exploitation [osdir.com]
• Vulnerability in Windows Kernel Could Allow Elevation of Privilege [microsoft.com]
• And many more...

For the lazy reader, almost every article here has the phrase "An attacker who successfully exploited this vulnerability could run arbitrary code in kernel mode." For the even lazier, allow me to summarize: "That's a Bad Thing"

Indeed, like any long-lasting public multi-version kernel, the Windows kernel has had a hefty share of vulnerabilities. What you said is just plain false. However, to the OP:

So this means your hypervisor can get infected? Is it really such a great idea to use the largest individual security risk in computers as a hypervisor?

You may want to think a little harder about what you mean by kernel [wikipedia.org]. Every hypervisor is a type of kernel. Some things that perform hypervisor-like roles are full-fledged kernels [wikipedia.org]. However, if you actually click the link in the article that you're quoting, you'd see that they're not talking even remotely about what you think they are. The article details how Microsoft is investigating changing some fundamental (read: legacy, UNIXy, etc.) kernel models and roles to take a shot at getting more successful multicore performance and a better user experience. It's less about "zomg Windows is a hypervisor" and more about "what traditional Kernel roles can we modify?"

If you understood even fundamental systems architecture concepts, you'd realize that Windows as a hypervisor is a lot less scary than Windows as a standalone OS, as the latter is not only handed full system control, but is also responsible for arbitrating userspace execution.

Corrections regarding F#

[shutdown -p now]

There are a few things in SDTimes article, in the bit where they talk about F#, which are incorrect:

For instance, F# is highly immutable—meaning that object states cannot be modified once created

This isn't really true. F# defaults to immutable locals and record/object fields, but you can always declare them as mutable explicitly if you want. In that, it's quite similar to OCaml, and quite different from Haskell. Example:

type Foo =
  let x = 0 // immutable field
  member this.Bar() =
    let y = x // immutable local
    y <- y + 1 // error
    x <- y // error
 
// Mutable class
type Foo =
  let mutable x = 0 // mutable field
  member this.Bar() =
    let mutable y = x // mutable local
    y <- y + 1 // okay
    x <- y // okay

And then also:

... and has an implicit type system

There's nothing "implicit" about F#'s type system - it's quite in-your-face, in fact even more so than in a typical OO language such as C# or Java. For example, it won't do automatic upcasts.

I guess what they meant there is that F# has Hindley-Milner type inference [wikipedia.org].

Re:where are you getting at?

[Anonymous Coward]

It would help if you'd bother reading the docs on Midori and the Singularity core it's built on.
For starters it's a microkernel, which, at least according to Liedke's principal of minimality offers flexibility and reliability through minimality. Because everything that isn't part of the microkernel is isolated from the kernel, and from other processes (via SIPs (Software Isolated Processes)) a service that crashes or goes goes does not take the kernel or anything else with it, instead the "service" is stopped, and detatched from everything depending on it, restarted and reattached - crashes behave like a web browser would, should the internet connection be severed - it just sits there and wait for the connection to be re-established, leaving you with a much more robust and reliable system.

Second, it also "acts like a hypervisor" (mind you, a hypervisor is little more than a glorified microkernel which doesn't completely adhere to Liedke's principal of minimality), to run an OS written entirely in managed code (Sing# and Spec# in this case, IIRC) which conveys they security benefits of managed code to the entire OS, leeaving you, once again, with as more secure and more reliable system, with a fun bonus that what is essentially the .NET framework becomes to Midori, what Win32 is to previous and current edditions of Windows.

There's also the ease of debugging and management argument; which is easier to manage, debug and ultimately least likely to contain critical bugs, a 4,000 line kernel, or a 15,000,000 line kernel? And the performance argument of old regarding microkernels don't apply here (and haven't really applied anyway, since L4 and much more so when hypervisors started popping up all over the place), I don't recall the number OTOH (but they're available at MSL's site under the section devoted to Singularity), though they manage to put out impressive perf numbers,. apparently mostly due to its use of SIPs, rather than more traditional means of process isolation..

All the information is readily available on MSL and has been for quite some time, in fact, the Singularity RDK has been freely available for at least two years now, and the whitepapers and such for longer. You'll find that MS has been fairlt forthcoming regarding the answers you're looking for.

Re:where are you getting at?

[Anonymous Coward]

These articles were not written by Microsoft to promote itself. These articles were written by outsiders to discuss the implications of the extremely little that people know about Midori.

Re:Wasn't Windows 95 and 98 built from the ground

[Cyberax]

Not exactly. Traditional microkernels turned out to be too slow and complex because of high overhead of context switching and complexity of distributed algorithms.

Microsoft is planning to replace context switches with statically-checked managed code. Managed code by its nature can work WITHOUT memory protection at all. And unmanaged code (aside from some thin driver-support code) can be nicely segregated into virtual machines.

It's actually quite a clever approach, not without its problems, of course.

Re:Wasn't Windows 95 and 98 built from the ground

[psetzer]

That's the problem with any software that's not running on bare iron. A C program running on Linux is still limited in the exact same way that managed code is. It's just that the OS imposes those limitations with SIGSEGV rather than simply not deallocating referenced memory. If it really did let you do whatever you want that the hardware allows, that'd be a tremendous security hole.