Microkernel: The Comeback? 722
bariswheel writes "In a paper co-authored by the Microkernel Maestro Andrew Tanenbaum, the fragility of modern kernels are addressed: "Current operating systems have two characteristics that make them unreliable and insecure: They are huge and they have very poor fault isolation. The Linux kernel has more than 2.5 million lines of code; the Windows XP kernel is more than twice as large." Consider this analogy: "Modern ships have multiple compartments within the hull; if one compartment springs a leak, only that one is flooded, not the entire hull. Current operating systems are like ships before compartmentalization was invented: Every leak can sink the ship." Clearly one argument here is security and reliability has surpassed performance in terms of priorities. Let's see if our good friend Linus chimes in here; hopefully we'll have ourselves another friendly conversation."
Eh hem. (Score:4, Insightful)
Isn't SELinux kinda like compartmentalization of the OS?
multicompartment isolation (Score:3, Insightful)
Solution: better code management and testing.
Re:multicompartment isolation (Score:5, Insightful)
Not entirely accurate (Score:4, Insightful)
The 2'nd approach(paravirtualization) could actually be used WRT linux as a means of not only separating the usermode from the device drivers, but it would also allow for some nice networking capabilities. After all, the average systems does not really need all the capabilities that is has. If a simple server(s) can be set up for the house and then multiple desktops without driver is set up, it simplifies life.
Lessons on evolutionary theory for Andy... (Score:2, Insightful)
So, let's all agree with Andy, then go on using the best tools for our purposes. If that happens to be Linux (or even Windoze), then so be it...
Hindsight is 20/20 (Score:4, Insightful)
"The limitations of MINIX relate at least partly to my being a professor: An explicit design goal was to make it run on cheap hardware so students could afford it. In particular, for years it ran on a regular 4.77 MHZ PC with no hard disk. You could do everything here including modify and recompile the system. Just for the record, as of about 1 year ago, there were two versions, one for the PC (360K diskettes) and one for the 286/386 (1.2M). The PC version was outselling the 286/386 version by 2 to 1. I don't have figures, but my guess is that the fraction of the 60 million existing PCs that are 386/486 machines as opposed to 8088/286/680x0 etc is small. Among students it is even smaller. Making software free, but only for folks with enough money to buy first class hardware is an interesting concept. Of course 5 years from now that will be different, but 5 years from now everyone will be running free GNU on their 200 MIPS, 64M SPARCstation-5."
Re:multicompartment isolation (Score:3, Insightful)
It actually took hitting something like half the compartments to sink her. If it had hit just one less compartment, she would have stay afloat. In contrast, one hole in a none compartmentalized ship can sink it.
That is no different than an OS. In just about any monolithic OS, one bug is enough to sink them.
A false dichotomy (Score:5, Insightful)
When viewed as a Platonic Ideal, a microkernel architechture is a useful way to think about an OS, but most real-world applications will have to make compromises for compatibility, performance, quirky hardware, schedule, marketing glitz, and so on. That's just the way it is.
In other words, I'd rather have a microkernel than a monolithic kernel, but I would rather have a monolithic kernel that does what I need (runs my software, runs on my hardware, runs fast) that a micokernel that sits in a lab. It is more realistic to ask for a kernel that is more microkernel-like, but still does what I need.
Re:Proof is in the pudding (Score:4, Insightful)
Re:Oh Dear (Score:5, Insightful)
All I ask is that the GUI is reasonably slick, the screen design doesn't actively give me hives and the mail application is pleasant. Performance? Within reason, I really couldn't care less.
ian
Re:The thing is... (Score:5, Insightful)
Comparments do interfere with efficient operation, which is why Titanic's designers only went halfway. Full watertight bulkheads and a longitudinal one would have screwed up the vistas of the great dining rooms and first class cabins. It would also have made communication between parts of the ship more difficult as watertight bulkheads tend to have a limited number of doors.
The analogy is actually quite apt: more watertight security leads to decreased usability, but a hybrid system (Titanic's) can only delay the inevitable, not prevent it, and nothing really helps when someone is lobbing high explosives at you from surprise.
friendly conversation (Score:3, Insightful)
"Andy:
The most interesting part: "Linus: The very
Re:Feh. (Score:3, Insightful)
The industry has better and more important things to worry about.
Like what? Reliability and security ought to be paramount. The IT industry (relating to multipurpose computers, anyway) is currently a joke in that area - compare to virtually any other industry.
OS X - First make it work, then make it fast (Score:5, Insightful)
First make it work, then make it fast
Specifically:
Write it as simply and cleanly as you can,
THEN check performance,
THEN optimize, but ONLY where measurement tells you to.
Judging by the performance improvements over time, this is what the OS X team has been doing. Their stuff has been getting bigger, with more functionality, AND faster on the same hardware, with each release. If anyone else has been doing that, I haven't heard of it.
Titanic (Score:4, Insightful)
How is kernel compartmentalization going to protect against users installing spyware and doing things they're already authorized to do?
This has always bugged me about this argument (Score:4, Insightful)
In Andrew Tanenbaum's world, a driver developer can write a driver, and not even realize the thing is being restarted every 5 minutes because of some bug. This sort of thing could even get into a shipping product, with who knows what security and performance implications.
Re:Proof is in the pudding (Score:3, Insightful)
The problem is the hardware is optimized for something else now. Also, modern programmers that only know Java can't code ASM and understand the hardware worth a damn. I should know, I have to try and teach them.
And yes, all people care about is speed, becasue you cannot benchmark securrity, and benchmarks are all marketing people understand, and gamers need something to brag about.
Re:Metaphors eh? (Score:4, Insightful)
-matthew
Virtualization (Score:5, Insightful)
It seems reasonable to think that a tiny microkernel built for virtualization and able to support multiple virtual os's with minimal overhead is really going to be a very attractive platform. If we then get minimal, very application specific kernels to run on top of it for specific needs, we could get an environment in which various applications (http servers, databases, network servers of other sorts, browsers) could run in secure environments which could leverage multi-processor architectures, provide for increased user security, make inter-os communications work nicely and generally be a Good Thing. Certainly that would not prohibit running complete unix/MS/??? systems from running as well. (Granting, of course, that OS vendors go along with the idea, which some of the big players may find economically threatening.)
Could be very fun stuff and make viable setups that are currently difficult or impossible to manage well.
Re:Practice != Theory (Score:2, Insightful)
To use his metaphor, what good does sealing off the one leaking compartment do if crew can not survive without it? Sure the ship may still float, and you can replace the crew, but they are still just as dead as if the ship had sunk.
Re:This has always bugged me about this argument (Score:3, Insightful)
Some hurdles... (Score:2, Insightful)
So, to return to the microkernel-like statement, I think that modern OSes *ARE* trying to achieve the goals that Tanenbaum aspires to. The points he brings up *ARE* being addressed in Linux, Windows, and Mac OS X. The contention is that they will not happen overnight, and they will only happen faster as more negative feedback is fed into the mechanisms of change, i.e., the project development community or corporate entity doing the work. But, corporate entities in particular have to balance the equation. They can't just sacrifice performance and compatibility for the sole sake of reliability and security. I don't believe that Tanenbaum would disagree with that point. We are seeing more compartmentalization (modularization if you will) within the structure of most OS kernels. I think his wrapper idea for device drivers has merit. Personally, I'd rather see a common driver framework developed for categories of devices to help minimize the number of driver specific wrappers that would need to be created manually (455 seems like a tremendously large number). Virtualization is growing in popularity in the IT community at large. I think there are some huge benefits to this that will alter OS development in the future, the near future for some things. His two more holistic approaches are novel. I think the Multiserver approach may have more of a chance than the Laguage-Based approach, but time will tell which theory takes hold in practice, or if a new or hybrid approach may emerge.
All-in-all a good read and definitely thought and discussion provoking.
Re:Lessons on ID for csoto (Score:3, Insightful)
That's looking at it from an end-user standpoint. The problem with that view is that the better method will never become viable.
To extend your evolution metaphor, you're limiting yourself to a subset of the genepool. Sure, a species that has already been selected for / adapted to that particular niche would outcompete *now* in that niche; but that does not mean that another species allowed to adapt to that niche wouldn' out-compete the one that's already there -- especially should conditions change in that niche (as constantly happens with technology).
To give a biological example, look at the large animals of the Americas. They evolved to fill niches in the absence of humans. Once humans came over, they were all killed off or died out most likely as a result of human interference -- they hadn't the traits to survive in the new niche (with the exception of the buffalo). Yet big animals in Africa survived alongside human hunters -- they would have been better suited to the 'new' American niche.
My point is that just because something has the most developed tools for the job *now* doesn't mean that it's lineal successors would be the best tool for the job *later*. Who knows what we're missing if we limit ourselves to the current development lines?
Offtopic: Lusitania (Score:1, Insightful)
A while back, I did a little bit of research into the Lusitania's sinking, and concluded there was ample evidence to lead one to believe she was carrying munitions. The original design of the ship had deck guns, and while I believe they were removed for extra speed, the Lusitania had indeed been used for smuggling munitions in the past using civilians as a cover. However, Google came up with this link [pbs.org] containing some evidence that pointed to a coal dust explosion, and not munitions. But, the Germans probably would have sunk it regardless, since they knew of Lusitania's dual purpose.
Re:How hard... (Score:3, Insightful)
Has anyone tried? (Score:3, Insightful)
Well, the nice thing about software in rom is that you can't write to it. If you can't inject your own code and unplugging and replugging the device does a full reset back to the factory code then there is a very limited about of damage a hacker can do.
Then too, sets capable of receiving a sophisticated digital signal (HDTV) have only recently come in to wide-spread use. To what extent has anyone even tried to gain control of a TV set's computer by sending malformed data?
What, like VM boundaries are the only way? (Score:5, Insightful)
"In the 1980s, performance counted for everything, and reliability and security were not yet on the radar" is remarkable. Not on whose radar? MVS wasn't and z/OS isn't a microkernel either, and the NCSC didn't give out B1 ratings lightly.
One thing I found interesting is the notion of running a parallel virtual machine solely to sandbox drivers you don't trust.
Re:Metaphors eh? (Score:2, Insightful)
Performance may be better (Score:2, Insightful)
It's all theory until we have a working example. (Score:2, Insightful)
Until such a thing exists for mainstream use, his comments are intellectually interesting but not really of much practical use.
Re:OS X - First make it work, then make it fast (Score:3, Insightful)
FIRST design the system, and make sure the algorithms and architecture are sufficiently straightforward and efficient.
No amount of optimizing will save you if your system is slow by design, and there is no place where this was more true than in the early microkernals. That is why the microkernel architecture was rejected by linux and windows kernel developers.
The Mach kernal has some fundamental effeciency issues, and while it has been improved since it's introduction, there are limits to how fast it can get. As such, Darwin is slower at many things compared to some monolithic kernels, and will continue to be slower unless they do some major revamping (ie redesign and rewrite the kernel) under the hood, not just tweeking.
In the end it is about trade-offs. The "make it right, then make it fast" approach depends on your idea of right. If you really want an example of "doing it right" with regards to security and stability, look to QNX or OpenBSD. None of the desktop OSes compare to those, because they all made compromises. Windows NT and Linux both decided that the loss of efficency was not worth the gains in stability / security that you get from having a microkernel. And honestly, this particular decision hasn't greatly harmed the stability / security of those systems as a whole.
Re:Proof is in the pudding (Score:2, Insightful)
How can they be including code from Apple and Linux? Wouldn't that produce licensing incompatibilities?
Re:Feh. (Score:1, Insightful)
Let me guess. They added more blades.
Re:Proof is in the pudding (Score:3, Insightful)
Certain types of security flaws are much harder to exploit when the OS addresses memory in unpredictable ways.
Other design principles, which encourage access log review, aid to the security of the system without having anything to do with code review.
Analogies are like... something. (Score:4, Insightful)
When it comes to security, imagine aliens trying to take over your ship...
This has got to be the best juxtaposition of two sentences ever found on Slashdot.
Re:Tanenbaum is wrong, and should know it (Score:5, Insightful)
- couldn't
DMA a mouse packet over scheduler code (which ought to be read-only at the MMU) or the MMU's page table.That is what Tannenbaum's research is asking. Can such a system be built? Does it perform? What are the tradeoffs? Does the end result offer enough benefits (reliability and security) to overcome the costs (performance)?
Re:Tanenbaum is wrong, and should know it (Score:4, Insightful)
I do believe that Tanenbaum was addressing security in his article, not kmem protection. His point was that the segregation of the servers prevents a hole in these programs from opening an elevated privledge attack. Furthermore, he points out that the elevated permissions of the kernel are likely to be far more secure due to the miniscule size of the kernel itself.
You make an interesting point about the stability of the kernel, but that wasn't his point in the slightest.
Re:How hard... (Score:3, Insightful)
Re:Isn't Tannenbaum the one who said... (Score:3, Insightful)
I think it is clear that Linux won that argument.
This is not at all clear. By what metric do you claim that Linux won that argument? Popularity? Then surely the Windows kernel wins even more.
Truth is, just because one technology is superior to another (in terms of, say, stability, maintainability, whatever) doesn't mean that it will immediately win in the marketplace. I think that Linux became a success because of other factors, such as that it was easy for people to contribute, and because it conservatively copied a 1970s design which everybody who wanted to contribute already understood.
The performance argument is of course rapidly declining in importance. I would gladly spend a little bit of performance for increased stability. In the 60s some people claimed that high-level languages would never fly - too slow. Turns out that there are more important things than CPU cycles.
ukernels are hard to code (Score:2, Insightful)
I played alot with AmigaDOS, a message-passing OS (it was a port of Tripos, an early research message-passing OS), as a teenager. That experience cured me of message-passing interest, because I found myself spending 75% of my time dealing with message-passing coding rather than dealing with the underlying hacks I was trying to perpetrate.
Not only did one have to write more code to make an MP call (comm overhead code), but the bugs had a way of showing up in that snippet and being harder to debug. The tiniest change in a driver's interface meant an hour of coding, vs the ten minutes I saw later for BSD Unix. At that, I was lucky. If I'd been dealing much with nontrivial synchronization and threading, I expect I would've seen more like the factor of ten coding slowdown I've always seen dealing with threading problems (and to be fair, most ukernel code doesn't have to either, it's just that there are more threads, more sync points, and thus more potential for trouble).
The basic problem is that modularization is a largely orthogonal problem from threading, address spaces, or messaging. If you split up modules into different threads, then now you don't just have to solve modularization, but you also have to solve threading, messaging, and address space problems, too. Now, address space separation seems like it might save some debugging troubles, and in fact, successful "monolithic" operating systems in fact deliver the simplest form of that. I've been a little surprised that attempts to push farther on that like Electric Fence or multi-address-space OS' with traditional system call architectures have gone nowhere. But they have, so the difficulties must exceed the return somehow.
Thus, I haven't been surprised to see ukernel project after ukernel project fail. The idea is at least forty years old, and has seen many smart people try to take it on - if a ukernel was going to succeed broadly, it would've happened by now.
If you like ukernel OS' even after reading this, I say go try one, and try hacking something in. Just watch how much time you spend actually writing code implementing the hack vs MPI / threading drudgery.
Re:QNX ! (Score:4, Insightful)
The sheduler, for example, is real time only so for non-real time applications is questionable at best. A simple problem to address in the open source world but, apparently "not a high priority" for the manufacturer of this fine technology.
-rant-
I fail to understand the point of closed source kernel implementations. The kernel is now a commodity.
-/rant-
]{
Re:Trusted Computing (Score:3, Insightful)
Trusted computing merely checks that the code hasn't changed since it was shipped. This verifies that no new bugs have been added and that no old old bugs have been fixed.
Re:Feh. (Score:3, Insightful)
Microkernels actually may help with that as well. If it is very obvious to the OS -- and to the user -- which drivers are crashing, that will provide incentive for the hardware vendors to write drivers correctly. Right now there is no accountability, so as long as the whole system works most of the time, users will buy it. But with microkernels, if new hardware comes out and you have review sites saying "That hardware driver is crashing left and right", users won't buy it. Nobody can point fingers anymore.
In particular, nobody will point fingers at MS Windows when the real problem is crappy 3rd party drivers.
Re:OS X - First make it work, then make it fast (Score:3, Insightful)
While it stops developers tweaking every possible piece of code to be an unreadable high-performance mess, I've also seen it used as an excuse to 'not think about performance now' at design time. Even when you are showing them evidence that they are repeating a known performance problem - and some performance problems require major restructuring - i.e. the stuff you can't fix by tuning the code inside a class, but because some dimwit designer is working at such an abstract level, they can't see that calling a web-service located in China, once per object, for thousands of objects, was NEVER going to work.
'Premature optimisation' is a usefully vague phrase - you can only know it was premature with hindsight. Rant over.
(But yes, it's nice that Apple improve performance with each release, although with Tiger it looks like that has been at the cost of needing more memory).