Slashdot Mirror
Microkernel: The Comeback?
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."
Current operating systems are like ships before compartmentalization was invented
Isn't SELinux kinda like compartmentalization of the OS?
BeOS didn't seem slow to me. No matter what I threw at it.
Back in the 80's and 90's, the argument for monolithic was performance. Considering that CPUs were so small, it made sense. If Linux had been on a micro kernel design, it would have been slower than MS. IOW, it would never have gotten off the ground.
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.
I prefer the "u" in honour as it seems to be missing these days.
From the link to the Linus vs. Tanenbaum arguement:
"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."
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.
OpenBSD's security strength has NOTHING to do with the kernel. It has to do with the fact that mulitple trained eyes are looking over code. The other thing that you will note is that they do not include new code in it. It is almost all older code that has been proven on other systems (read netbsd, apple, linux, etc). IOW, by being back several revs, they are gaining the advantage of everybody else as well as their own.
I prefer the "u" in honour as it seems to be missing these days.
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
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.
You can only drink 30 or 40 glasses of beer a day, no matter how rich you are.
-- Colonel Adolphus Busch
That friendly conversation is hilarious. "Linus: ...linux still beats the pants of minix in almost all areas"
...I still maintain the point that designing a monolithic kernel in 1991 is a fundamental error. Be thankful you are not my student. You would not get a high grade for such a design :-)"
/idea/ of an operating system is to use the hardware features, and hide them behind a layer of high-level calls. That is exactly what linux does: it just uses a bigger subset of the 386 features than other kernels seem to do. Of course this makes the kernel proper unportable, but it also makes for a /much/ simpler design. An acceptable trade-off, and one that made linux possible in the first place."
"Andy:
The most interesting part: "Linus: The very
How many times have we all heard that the proper way to develop software is:
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.
To a Lisp hacker, XML is S-expressions in drag.
I think the real question is what risks computers are facing these days. The Titanic had multiple compartments (up to a point), but the ice berg tore along the side, ripping off rivets and letting water pour in multiple compartments at once.
How is kernel compartmentalization going to protect against users installing spyware and doing things they're already authorized to do?
I never really understood why buggy drivers constantly restarting is a desirable state. Say what you will about the monolithic kernel, but the fact that one bad driver can crash the whole works tends to make people work much harder to create solid drivers that don't crash.
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.
The problem I have with the compartmentalized ship metaphor is that I question the value of being able to run a system that has one compartment "breached." The system may technically still run, but is it goign to be of any use in such a state? Aren't you going to want to reboot it anyway or is the theory that you can restart a component without rebooting? Is this realistic? Seems to me that a system would get into a pretty funky state depending on which component failed.
-matthew
"THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
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.
"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.
As always, all IMO. Insert "I think" everywhere grammatically possible.
Yeah, you got to be careful with analogies.
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.
-Forrest Cameranesi, Geek of all Trades
"I am Sam. Sam I am. I do not like trolls, flames, or spam."
- 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)?
Kernels don't often crash for reasons related to lack of memory protection.
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.
Javascript + Nintendo DSi = DSiCade
The QNX Neutrino kernel is a very good microkernel implementation (albeit not as purist as, say the Ka micro-kernel line, but the fact that it is not open makes it unusable.
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-
]{