"Midori" Concepts Materialize In .NET
106
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."
Will Linux get to enjoy "Distributed Concurrency"? (Score:2)
So MS is gonna get this "Distributed Concurrency" thing into Windows.
How about Linux?
When will Linux get enhanced by "Lidori" (Linux version of Midori)?
Re: (Score:2)
Linus (Score:2, Funny)
Presumably this is the project they hired Linus to head up? /ducks
Re:Wasn't Windows 95 and 98 built from the ground (Score:5, Informative)
Win9x were built upon DOS (although replaced and virtualised it underneath itself) and provided win16/32 calls etc as subsystems. They're talking here about a fresh codebase that runs as a hypervisor and executes managed code. The idea basically being kinda like a microkernel but with increased isolation using newer virtualisation technology rather than the old erm... virtual memory technology... which has never really been used to its full potential I don't think.
Re: (Score:3, Interesting)
Re: (Score:3, Insightful)
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.
Re: (Score:1, Interesting)
You miss the point. The problem with mainstream OSes is that once you run an app it's free to do anything you can do, which includes shitting all over your data. He's talking about limiting what applications can do, not letting them do more. Google Capability Security Model for details.
Re: (Score:2)
Re: (Score:3, Interesting)
"A C program running on Linux is still limited in the exact same way that managed code is"
Not really. Managed code will tend to grow buffers, moving them if need be, rather than allow one out-of-bounds write to a buffer overwrite something next to it as unmanaged code will do.
Re: (Score:2)
Not really. Managed code will use static analysis to prove that out-of-bounds writes will never happen.
Magically growing datastructures can be implemented in any language, managed or not.
Re: (Score:2)
"and executes managed code."
...rendering hopelessly inefficient all the programming languages that won't fit the execution model of the one particular managed code spec that MS chooses to implement. Goodbye, Scheme, continuations etc.
Re: (Score:1)
Not to be an MS apologist, but IronScheme runs on the .NET (or more specifically CLR) platform. Also F#--which will be included in VS 2010-- supports continuations (found during a quick Google search of f# and continuations). Not that this effects me too much since I'm primarily using Linux/FreeBSD these days, but should I ever end up on an MS system based on these ideas there may still be hope.
Re: (Score:2)
Re: (Score:2, Informative)
Contrary to what their marketing would have you believe it isn't anything like that. Infact, its more like firing up Windows 7 and replacing explorer with the hyperv manager.
Re: (Score:1)
The problem is they can't fix Windows so their coming up with a unique and non-obvious way to start from scratch without telling everyone they are starting from scratch.
They aren't actually doing anything new. Its just a different way to implement EXACTLY what we have in OSes now.
The REAL problem is ... when you have all these systems interacting with each other, they ALL have to be secure or it falls apart. Rewriting it isn't going to change that. I mean, sure it will in theory, and it will in practice
Re: (Score:2)
"without telling everyone they are starting from scratch"
What?! That's exactly what they're telling everyone. A new system as a replacement to Windows, written from the ground up around extended concurrency models (to take more advantage of multicore/proc) and protection.
"They aren't actually doing anything new. Its just a different way to implement EXACTLY what we have in OSes now"
You think it inconceivable that the differences might mean things that you haven't thought of??
What if you forget about "malici
Re: (Score:3, Insightful)
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: (Score:2)
Ahh... of course, you do away with MMU overhead, TLB flushes, stack overflows, and you can still translate much (if not all) to native code... if you can do that with lower overheads than context switching etc gives you, you've got a win. I've never really understood though why OSs (at least on x86, which is all I can comment on) rely so soley on the page table and TLB flushing as they do, while ignoring selector based protection and having them just map the whole of their address space. Eg, your code selec
Re: (Score:2)
Managed code by its nature can work WITHOUT memory protection at all.
How did you think the "management" worked? Either you trap each pointer access manually (and maintain all of that state and overhead), or you use a memory management unit to do it for you (and accept the cost of traps and context switches).
The very best that a VM runtime can do is infer that a class of access is impossible and thus exclude traps for it. This only works in extremely limited circumstances, and still requires code to be correct. It in fact makes profiling really difficult - and performance is
Re: (Score:2)
The very best that a VM runtime can do is infer that a class of access is impossible and thus exclude traps for it. This only works in extremely limited circumstances, and still requires code to be correct.
That's exactly what "managed code" means in this context: the VM spec and the JIT-time verifier prohibit the types of accesses that would need to be trapped.
For example, you can't dereference a pointer that might point to any arbitrary memory location, because the verifier won't let you cast an integer to a managed pointer; you can only get a managed pointer by taking the address of a variable. You can't dereference a pointer to a local variable in a stack frame that no longer exists, because the verifier w
Re:.. i must have seen that before (Score:4, Informative)
If it's anything like Singularity, then the point is to exploit static memory safety analysis (which is possible for sandboxed managed code) to avoid the overhead of virtual memory protection. Basically, if you have two processes for which you can statically prove that they never try to access each other's memory (e.g. because all pointer accesses are via pointers which are derived from heap allocations for that particular process, and no arithmetic is done on them that can put the result out of bounds of the original allocated block), then you can safely run them in a single memory space.
Re:.. i must have seen that before (Score:5, Interesting)
Midori [wikipedia.org] is just a first stab at a commercial version of Singularity. When I was working at MS a few years ago Midori was already being worked on; some of Windows built-in apps were being converted to run on it so they had something to test with it. It's not exactly new, and it's only a step or two from the Research group; I don't expect to see an actual released OS from the project for a long time.
From my impression of the project, it was mostly about finding a way to make the OS scale to massively multi-core machines; Windows can run on a many-core OS, but eventually all the locking and contention at the kernel level starts costing you a lot. Both the OS and the associated .NET-like language are designed to put constraints on the programming such that the processes can be parallelized efficiently without excessive locking.
Re: (Score:2)
Locking and contention is a matter of design. It the Windows kernel does not scale well for multicore machines, it seems it is not designed correctly; just like Linux had a big kernel lock a few years back.
And if I want to write ass
Re: (Score:2)
Depends on how you define either one.
Anyway, Wikipedia has a more detailed high-level description [wikipedia.org] of Singularity, and the source code for it is available [codeplex.com] (use, modification and redistribution allowed non-commercial academic use only - not FLOSS). Assuming that Midori is a further development from that (and we don't really know), you can take a look at those two and judge for yourself.
Re: (Score:2)
If it's anything like Singularity, then the point is to exploit static memory safety analysis (which is possible for sandboxed managed code) to avoid the overhead of virtual memory protection.
That's been tried many times before, including with runtimes like Java, with signed code, and even with program analysis.
It's going to fail. Most of the commercial processors have virtual memory hardware. Even if eliminating it would result in speedups, no processor without virtual memory hardware is going to be opti
Re: (Score:2)
That's been tried many times before, including with runtimes like Java, with signed code, and even with program analysis.
It's all of the above, with DbC thrown into the mix.
It's going to fail. Most of the commercial processors have virtual memory hardware. Even if eliminating it would result in speedups, no processor without virtual memory hardware is going to be optimized as much as the mainstream processors that have it. As a result, in practice, this is going to be slower. And even if they succeed in that, we would have to throw away most of the software and compilers we already have; it's not going to happen.
Probably not in near future. However, consider this: Windows Phone 7 restricts software to managed & sandboxed only. Is it just to limit features and contain potential malware, or is there a long-term plan there?..
These Microsoft projects are just academic
True.
they are not going to lead anywhere.
That doesn't follow. Typical software development methodologies and tools of today were considered academic a few decades ago (e.g. OOP was an obscure academic experiment for quite some time; more recently, FP has been transitioning from
Re:Hypervisor (Score:4, Insightful)
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: (Score:1, Troll)
Re: (Score:1, Insightful)
It may as well be.
Re:Hypervisor (Score:4, Informative)
I believe he was stating that Microsofts ring 0 processes usually arent the security risk.
Re: (Score:1)
Re: (Score:1, Troll)
Re:Hypervisor (Score:4, Informative)
The userspace?
Re:Hypervisor (Score:5, Informative)
The userland api and applications, mostly.
Re:Hypervisor (Score:5, Insightful)
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:
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.
Re: (Score:1)
Re: (Score:1)
But it wasn't even Microsoft's fault, it was a bug in the rootkit code. They overwrote OS code they though never gets updated, and when MS update patched it.. well, crash.
Re: (Score:2)
What are you smoking? Windows kernel itself hasn't really been vulnerable to anything, it's the third party software
but there have been several security updates for the kernel, so its more a case of what are you drinking?
(the MS koolaid, obviously).
As for 3rd party apps, yes, that true there are way more vulnerabilities in them, but that mostly applies to the Windows userland apps. I can tell how many vulnerabilities there are in Windows simply by looking at my update history - all those critical updates ar
Re: (Score:2)
Of course it's mostly the application programs and libraries that get hacked. But the Windows kernel is ultimately responsible for those vulnerabilities because it defines the security and protection model that application programmers have to use. A well-designed kernel should make it hard to write software that is vulnerable.
Re:Hypervisor viruses (Score:2)
Sure there is a small potential, but it works well for 100's of thousands of ESX installs..
Re: (Score:1)
They're just trying to make it so their problems affect everybody. That way, it's more likely that things like this http://www.computerworld.com/s/article/9164438/Microsoft_s_security_chief_suggests_Net_tax_to_clean_computers [computerworld.com] would be seriously considered by governments for example. And it becomes a way for them to try to reclaim Linux servers [so you still pay a Microsoft tax even if you run Linux servers...
Re:Oh? (Score:4, Funny)
Re: (Score:2)
Re: (Score:1)
A hypervisor (Score:2)
That is tied to the Microsoft 'cloud' for its core functionality.. A return to the mainframe days where if you don't continue to pay, you don't have squat.
Re: (Score:2)
Re: (Score:2)
Smoking? No. However i do read papers that Microsoft publish that outlines their long term roadmap.
Midori is a step in the direction of a cloud based desktop, which is a stated goal. ( as is the current slow migration of their back office products )
TFA (Score:5, Funny)
Yep, bright future ahead.
where are you getting at? (Score:2, Troll)
As always, MS, you're right that there are abstraction improvements which can be made at systems and app level, but as always, MS, you're never clear about what the problem is and what you're offering with your solution.
What do I get with Midori that I didn't get before? What's going to improve, for programmer or user?
Re:where are you getting at? (Score:4, Insightful)
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: (Score:2)
No, you're inventing a problem ("insecure, hard to manage kernels/services") and proposing a solution ("the microkernel!") in the style of Tanenbaum vs Torvalds back in '91. There tends not to be a problem with stable, insecure kernels on modern server platforms.
MS appear to be offering an Ocaml implementation, right? And then want to implement everything system-flavoured under it, in the style of a LISP machine, right?
Re: (Score:1, Insightful)
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: (Score:1)
Its going to be exactly like we have now, except basically you'll have two layers of kernels and abstraction to go through instead of one!
Corrections regarding F# (Score:5, Insightful)
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:
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: (Score:2)
Re: (Score:1)
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.
Actually "implicit" is a pretty decent description of type systems that do type inference.
What's the definition of "implicit"? Random House says (for the first definition), "implied, rather than expressly stated." But this is exactly what happens in a language like ML or Haskell. If I say "fun f x = x + 1", I have not e
Re: (Score:1)
In fact, take a look at that Wikipedia article that you linked to. Here's how it starts: "Type inference, or implicit typing, refers to the ability to deduce automatically the type of a value..." (my emphasis).
Re: (Score:2)
Fair enough. I must admit that it's the first time I've heard the word used in this context, though. But then I can't even complain about how WP may be incorrect, since I was the one to link to it... pwned all the way. ~
Re: (Score:2)
Of course, typing in F# (assuming it works the same way as in OCaml, which, as far as I know, it does) is not really implicit, it's just that the types are specified by the operations when they aren't specified explicitly.
If you write
the + says that x and y are ints just as surely as if you had written
Still, it is true that, in the first example, the name of the type doesn't occur anywhere. So I think that is what people mean when they say "implicit".
Re: (Score:2)
Of course, typing in F# (assuming it works the same way as in OCaml, which, as far as I know, it does)
It does with a few exceptions. Specifically for + (and other arithmetic operators), they're overloaded on int and float, rather than having separate operator +. etc for float as in OCaml.
However, they're not properly polymorphic, in a sense that there's no way to constrain a type on "having operator +" (which would require proper type classes) - so, when it sees + in a context of some unknown type 'a, it has to constrain 'a to be a specific type with +, and it always picks int, so your example still works a
No good (Score:1)
Midori?!? (Score:1)
What does my lovely Guitar Hero waifu have to do with anything MS does??
Midori? (Score:5, Funny)
Managed code? (Score:2)
Re: (Score:2)
I doubt it.
eg. from TFA:
The Midori programming model includes Bartok, an MSR project that endeavored to create a lightweight compiled and managed runtime system that was more efficient than the .NET Framework
So maybe its not quite .NET after all. Anyhow, I think this research project is something that they;'re using to take the good ideas out of - especially where they apply to cloud computing as MS doesn't really have much there yet and they see it as a great way of making you pay for a subscription to their software instead of a one-off purchase.
As for C/C++, there's a reason game programmers write in those languages and not .NET, though you do see some more strategy-based games coming
Re: (Score:2)
Re: (Score:2)
Right, but if Midori replaces Windows, what's going to happen to PC gaming
Bubble Bobble?
Re:Offtopic, but I hope with an os redesign that t (Score:2)
Re: (Score:2)
I know what you mean, and I share your pain. This has long been a pet peeve of mine, too.
Interestingly, instances where focus has been stolen from me have markedly decreased in recent years, from where they were a constant annoyance to the point where I almost completely forget about the phenomenon and spend several minutes recovering after it happens.
The reason, it seems to me, is that I have switched to (1) terminal-based apps for most of my activities and (2) tabbed browsing. The result is that I really
Those who don't understand UNIX ... (Score:1, Troll)
are condemned to reinvent it, poorly.
old hat; try solving the hard problems instead (Score:2)
These "operating system concepts" have been explored at length in systems like Plan 9, Inferno, Mach, various Java distributed toolkits, agent-based programming, and God knows how many more obscure operating systems and platforms.
As usual, Microsoft is late and non-innovative. If Microsoft had actually managed to deliver a commercial kernel based on those concepts, that might have been interesting. But just folding the stuff into .NET is the same kind of retreat everybody else who has tried this has made:
Re: (Score:2)
I've already been awarded Troll for expressing my doubts that MS is clear about what problem it's solving (instead just experimenting with a tech and then shoehorning some of it into a low-risk existing product, as is typical for them), but I think it's clear that, aware that they can't just replace one OS kernel with another, their ostensible intention is to begin by offering their new magic as a VM on top of Windows. If Silverlight is their delivery platform, I'll be surprised if they don't get the same r