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?
didn't save the Titanic. Every microkernel system I've seen has been terribly slow due to message passing overhead. While it may make marginal sense from a security standpoint to isolate drivers into userland processes, the upshot is that if a critical driver goes *poof!* the system still goes down.
Solution: better code management and testing.
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.
Dearest Andy, please take some University courses on evolutionary biology. Perhaps you will take away a meaningful sense of the differences between "optimal" and "sufficient." I agree 100% with what you say. "Microkernels are better." That being said, this does nothing to diminish the viability of Linux, or any other monolithic system. Evolution only requires that a species retain sufficient qualities to ensure survivability (and therefore reproduction) in a given environment. "Perfection" never enters the equation (not even qualifiers such as "best" or "better" - just "good enough").
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...
There exists no way of exchanging information without making judgments. --Bene Gesserit Axiom
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
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.
If you're not part of the solution, you're part of the precipitate.
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.
Actually, it's been proven over and over that microkernel designs dont HAVE to be slow. Read the Liedtke paper on IPC in L3 from 1993 as one example.
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.
- Adam L. Beberg - The Cosm Project - http://www.mithral.com/
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.
His research is no more PRACTICAL than it was 20 years ago. Sure, in theory it is great that you can isolate faults and restart servers. In practice, what good does it do when restarting a crashed filesystem server process means that all the real user programs crash because their file descriptors have become invalid?
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.
After reading the paper and contemplating some issues, I do believe a microkernel-like approach is favorable for what Tanenbaum wants to focus on; reliability and security. I say "microkernel-like" because micro is a relative term when you think about the growing complexity of applications and devices a modern operating system has to deal with. I think his TV analogy falls flat on its face UNLESS you are willing to tailor individual operating system distributions to vertical markets. This is not at all practical in the open-source/FOSS space, and even less so in the commercial OS space. Who wants to write different kernels and services for every possible use a mixed set of hardware and software could be put to? His more reliable and secure consumer product examples are just that, embedded and highly specialized versions of an operating system. It can be done in the consumer electronics space because the cost of doing this is passed on to the customer and figured into the retail price. Since the OS and the hardware are removed from each other in all but a few cases, i.e. Apple and Mac OS, Sun and Solaris, and the now defunct SGI and IRIX, it is extraordinarily difficult (and costly) to achieve Tanenbaum's goals.
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.
"So, let's all agree with Andy, then go on using the best tools for our purposes."
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?
"Trolls they were, but filled with the evil will of their master: a fell race..." -- J.R.R. Tolkien on Olog-hai
Both would have survived the iceberg collision, which really does make one wonder what was in Lusitania's holds when those torpedoes hit her.
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 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.
Check out mkLinux and L4Linux. The efforts are made. The userland linux service on a microkernel is a reality.
Why are TV sets, DVD recorders, MP3 players, cell phones, and other software-laden electronic devices reliable and secure but computers are not?
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?
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
"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.
Simple. With a compartmentalized ship you can repair or replace the faulty compartment while still at sea. With a single-compartment ship (with damage way below the waterline) you have to take it to the dry dock to do repairs (that is, if you're able to keep it afloat that long anyway...)
The Hacker's Guide To The Kernel: Don't panic()!
Performance may be better in the long run with a microkernel. Sure, there is bound to be a performance penalty in message passing (and checking) with a modularized architecture. But since the developers would (hopefully) spend a lots less time tracking down bugs through a massive kernel, perhaps they could devote a lot more time to perfomance improvement work in the code? I have to imagine that kernels like Linux, OSX, and XP have lots of old, nightmare code that is horribly inefficient; the developers probably just haven't gotten around to improving it because they're too busy tracking down bugs and security breaches, or implementing drivers for the latest gadget.
And I'm not talking a MINIX-style example which is only good for classroom study -- I'm talking about a production-level operating system which can handle real-world task loads.
Until such a thing exists for mainstream use, his comments are intellectually interesting but not really of much practical use.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
How can they be including code from Apple and Linux? Wouldn't that produce licensing incompatibilities?
Let me guess. They added more blades.
Wrong. OpenBSDs strength is partially because of their testing and code review policy, but ALSO because of design issues (like kernel memory management).
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.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
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
Another example of this approach is libusb. Instead of providing drivers for USB devices inside the kernel, you can do that with libusb. It gives you an interface to the USB system. Many scanner and printer drivers use it, and the drivers are included in the CUPS or SANE packages.
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.
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.
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-
]{
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.
-- The act of censorship is always worse than whatever is being censored. Always.
But I'd even more prefer to see the driver written correctly to start with!
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.
Social scientists are inspired by theories; scientists are humbled by facts.