Slashdot Mirror
"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."
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.
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.
The revolution will not be televised... but it will have a page on Wikipedia
Yep, bright future ahead.
I believe he was stating that Microsofts ring 0 processes usually arent the security risk.
And here I thought it was Midori. Perhaps she and SteveB could discuss alternative uses for chairs or something.
The userspace?
The userland api and applications, mostly.
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 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. Every hypervisor is a type of kernel. Some things that perform hypervisor-like roles are full-fledged kernels. 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.
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.
Managed code doesn't fix things, because it doesn't allow the user to decide how his computer should be used by an application he's decided to execute. Nothing to date seems to do this basic task, outside of some stuff in research or military land.
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.
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.
Forget about Midori ... I want to know when parts of Mojave will find their way into Windows and .net !!
Tired of FB/Google censorship? Visit UNCENSORED!
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.
Midori 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.
$_ = "wftedskaebjgdpjgidbsmnjgcdwatb"; tr/a-z/oh, turtleneck Phrase Jar!/; print
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.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
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.
"Anyone who attempts to generate random numbers by deterministic means is living in a state of sin." -- John von Neumann
"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.
The revolution will not be televised... but it will have a page on Wikipedia