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."
Presumably this is the project they hired Linus to head up? /ducks
Mod me down, my New Earth Global Warmingist friends!
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
Internet explorer is third party? O.o
"Now I am become Death, the destroyer of worlds"
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.
---- Booth was a patriot ----
Sure there is a small potential, but it works well for 100's of thousands of ESX installs..
---- Booth was a patriot ----
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 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...
Sleep your way to a whiter smile...date a dentist!
It may as well be.
Then what is Microsoft patching every month?
Yep, bright future ahead.
I believe he was stating that Microsofts ring 0 processes usually arent the security risk.
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?
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.
Given that the topic is "distributed concurrency", I find the Borg Gates pic especially fitting for the occasion. :)
Ezekiel 23:20
Name one successful Flash exploit out there. I could name several in the core windows services... Conficker, for one.
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.
"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.
Ezekiel 23:20
It left sour taste in my mouth.
Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
What does my lovely Guitar Hero waifu have to do with anything MS does??
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!
And here I thought it was Midori
1331461 is only semiprime *sigh* Alas - I am just short of 1337.
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.
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 aren't distributed for fun.
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.
Will this spell the death of of unmanaged programming languages like C and C++ and the respective software developers who uses those languages? How will people such as game developers, who are heavily entrenched in C++ development, migrate themselves and their game engines and code bases to this new operating system?
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 right up until the point where the OS actually becomes useful for something. Why? Because to actually be useful you have to interact with something else. Notepad is useless if it can't take keyboard input/display output. Its worth is questionable at best if it can't print. Saving and loading are rather important. Even in a simple app like notepad there are many interactions between components of differing levels of access. By the time 'Midori' becomes useful, all these things will be back.
Applications within the OS are already supposed to be 'virtualized' and 'isolated' ... you know ... thats what the OS is supposed to do already.
All we're doing is making the shared portion of our computers smaller and smaller, which means bloat bloat bloat and issues with updating all the various bits multiple times.
It really bothers me that people thing vmware/hyper-v/virtualbox are acceptable. If the OS actually did its job right, these wouldn't be needed. When you use these tools you're just running multiple OSes. You've solved nothing and added more bloat and bugs.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
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
Yes, and Gambit Scheme is still miles ahead. You will never beat native code compilers on this. If anything, microkernels are the way to go. Language-based security enforcement OSes work for...well, supported languages. All the others will be either slow (either interpreted code or compiled code with workarounds) or simply unsupported. Say "no" to serious programming language research on such a platform, unless unmanaged code will be supported as well.
Ezekiel 23:20
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
Depends on how you define either one.
Anyway, Wikipedia has a more detailed high-level description of Singularity, and the source code for it is available (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.
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.
I second that motion, kill ugly popups. Or at least, delay them until there's sufficient pause in my typing...
And here I thought it was Midori.
"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 "malicious" for a moment (there's TPM chips for that) and think 'bugs'? With so many stability issues with Windows related to bugs in third party drivers and software, virtualising hardware interaction can be very beneficial, such as to the DMA chips. Without virtualising this, buggy drivers can end up reading/writing all over memory, beyond what permissions in the page table would allow CPU memory access. Windows wouldn't be the only OS to ever have problems with that occuring.
"Applications within the OS are already supposed to be 'virtualized' and 'isolated' ... you know ... thats what the OS is supposed to do already"
Well OSs often only really use a couple of the CPUs protection rings, with either all-in ring0 or all-out ring3. With "all or nothing", anything needing more than nothing needs to take everything. Evidentally whatever they're doing isn't always 100% successful, and one thing can crash another, even when there's no reason why those two things should be able to influence each other at all. Ignoring this fact and not putting some research into other ways of tacking the problem... well, would be pretty stupid, so I don't know why you would suggest that trying something that's not working in a different way would be a bad thing.
"All we're doing is making the shared portion of our computers smaller and smaller"
Yeah, why should your network card driver be able to read/write to memory allocated to your filesystem driver? These bits of memory shouldn't be shared. It doesn't mean "bloat bloat bloat"; you're not duplicating the filesystem drivers memory to allow the network card driver to write over its own copy of it "safely"; the network driver just doesn't get to see it at all.
"It really bothers me that people thing vmware/hyper-v/virtualbox are acceptable"
Well go on then Mr Perfect, write the perfect operating system that doesn't need them... making no mistakes ever, and not accepting any help of anybody who you couldn't absolutely guarentee wouldn't make any mistakes either.
It really bothers me that people think you should ignore a problem, and any solutions for the problem, simply because you don't think the problem should exist.
There's a reason why layers of abstraction occur in computing. Don't convince yourself that there can be no reason for something just because you can't think of it yourself. There's a lot of people out there. They will think of things you don't.
The revolution will not be televised... but it will have a page on Wikipedia
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 selector should not allow higher memory access than the bottom of your stack, and as your stack maps from the top of the stack selectors limit, different processes stacks could be placed at different places in memory, rather than at the same "the top of the address space" which requires flushing those TLBs between context switches. I suppose it would make calling conventions harder where the stack's used for storage... I dunno, I'm rambling, just surprised they seem so under utilised.
Cheers for that info anyway.
The revolution will not be televised... but it will have a page on Wikipedia
"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
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: they all started off dreaming of building the next gen OS, and they all ended up with a bunch of bloated libraries and frameworks that are barely used.
The tough part is not figuring out what the right thing to do is in this area, the tough part is figuring out how to build a real operating system around it that real developers and users will actually want to use.
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 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.
A much more sensible way is to add some kind of pointer verification to our processors. That way, existing programs could run more safely without a rewrite. In fact, that's already feasible for many programs even just using existing hardware, and hardware changes would be minimal.
These Microsoft projects are just academic; they are not going to lead anywhere. But even as academic interests, they don't really deliver much innovation.
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.
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 academia to mainstream).
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 the whole problem in the first place.
Sam ty sig.
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)?
Muchas Gracias, Señor Edward Snowden !
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 won't let you return the pointer out of that frame, and won't let any other function store the pointer anywhere except in an even deeper stack frame. This is checked statically, before the code runs, and then doesn't need to be checked again. (Certain operations do need runtime checking, like object casts and array access.)
The circumstances in which it works aren't really all that limited: just look at all the programs that have been written for .NET and Java. As for requiring code to be correct, well, that's what the verifier is for.
Visual IRC: Fast. Powerful. Free.
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.
SELinux / AppArmor, but more so, then ?
What a depressingly stupid machine.
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 assembly because I have a part of my app that requires performance not offered by .NET? Then I would have to use another operating system.
The real issue in scaling is the hardware. I don't understand why CPUs don't offer hardware-based in-process component isolation. As CPUs are currently designed, it's all (no isolation) or nothing (user-supervisor mode). There needs to be a better component isolation between components within a process.
Even so (joking aside this time), third party is not the correct verbiage to express that. Third party suggests made by a party external to Microsoft.
"Now I am become Death, the destroyer of worlds"
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 only have a few windows open at any given time, and I very rarely open new windows. This has made the focus stealing problem almost disappear.
Then I discovered that my next annoyance was window placement. It was never quite right, windows always ended up in the wrong place or overlapping the part of another window I needed most. Then I discovered tiling window managers, and that problem went away, too. I now basically have a bunch of full-screen windows which I can access by keyboard shortcut (e.g. Alt+1 is my terminal, Alt+2 is my browser). I've been using this setup for a few years now, and I have been happy with it.
Perhaps something similar will work for you. Good luck!
Please correct me if I got my facts wrong.