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."

Eh hem.

[suso (153703)]

Current operating systems are like ships before compartmentalization was invented

Isn't SELinux kinda like compartmentalization of the OS?

Re:Eh hem.

[Ohreally_factor (593551)]

Ship analogies are confusing and a tool of the devil.

Could someone out this into an easy-to-understand car analogy, like the good Lord intended?

Re:Eh hem.

[Kjella (173770)]

Isn't SELinux kinda like compartmentalization of the OS?

No, it's compartmentalization of the applications. Besides, the analogy is really bad because a ship with a blown compartment is quite useful. Computers with a blown network driver will e.g. break any network connections going on, in other words a massive failure. What about a hard disk controller which crashes while data is being written? Drivers should not crash, period. Trying to make a system that could survive driver failure will just lead to kernel bloat with recovery code.

The unsinkable Kernel

[Random Destruction (866027)]

So this microkernel is the unsinkable kernel?
FULL SPEED AHEAD!

Or...

[Mr. Underbridge (666784)]

You could just have a small monolithic kernel, and do as much as possible in userland.

Best of both worlds, no? Wow, I wish someone would make such an operating system...

The thing is...

[gowen (141411)]

Container ships don't have to move cargo from one part of the ship to another, on a regular basis. You load it up, sail off, and then unload at the other end of the journey. If the stuff in the bow had to be transported to the stern every twelve hours, you'd probably find fewer enormous steel bulkheads between them, and more wide doors.

Re:The thing is...

[crawling_chaos (23007)]

Compartmentalization had very little to do with the advent of the container ship. Titanic was partially compartmented, but they didn't run above the waterline, so that the breach of several bow compartments led to overtopping of the remainder and the eventual loss of the ship. Lusitania and Mauretania were built with full compartments and even one longitudinal bulkhead because the Royal Navy funded them in part to use as auxilliary troopships. Both would have survived the iceberg collision, which really does make one wonder what was in Lusitania's holds when those torpedoes hit her.

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.

Analogies are like... something.

[Pfhorrest (545131)]

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.

Theory Vs. Practice

[mikeisme77 (938209)]

This sounds great in theory, but in reality it would be impractical. 2.5 million lines of code handling all of the necessary things the Linux Kernel handles really isn't that bad. Adding compartmentalization into the mix will only make it more complicated and make it more likely for a hole to spring somewhere in the "hull"--maybe only one compartment will be flooded then, but the hole may be harder to patch. However, I wouldn't rule compartmentalization out completely, but it should be understood that doing so will increase the complexity/size and not necessarily lower the size/complexity. And isn't Windows XP or Vista like 30 million lines of code (or more)? That's a LOT more than double the size of the Linux kernel...

Re:Theory Vs. Practice

[Shazow (263582)]

wouldn't rule compartmentalization out completely, but it should be understood that doing so will increase the complexity/size and not necessarily lower the size/complexity.

Just to clear things up, my understanding is that Tanenbaum is advocating moving the complexity out of kernel space to user space (such as drivers). So you wouldn't be lowering the size/complexity of the kernel altogether, you'd just be moving huge portions of it to a place where it can't do as much damage to the system. Then the kernel just becomes one big manager which tells the OS what it's allowed to do and how.

- shazow

Re:Theory Vs. Practice

[mikeisme77 (938209)]

But then you'd have issues with performance and such. The reason the current items are in the kernel to begin with have to do with the need for them to be able to easily communicate with one another and their need to be able to have system override access to all resources. It does make his claim more valid, but it's still not a good idea in practice (unless you're primary focus for an OS is security rather than performance). I also still think that this method would make the various "kernel" components harder to manage/patch--I put kernel in quotes because the parts that would be moved to user land would still be part of the kernel to me (even if not physically).

Re:Theory Vs. Practice

[zhiwenchong (155773)]

In theory, there is no difference between theory and practice. But, in practice, there is.

- Jan L.A. van de Snepscheut

Sorry, couldn't resist. ;-)

A compromise needs to be made.

[Ayanami Rei (621112)]

Most drivers don't need to run in kernel mode (read: any USB device driver)... or at least they don't need to run in response to system calls.
The hardware manipulating parts kernel should stick to providing higher-level APIs for most bus and system protocols and provide async-io for kernel and user space. If most kernel mode drivers that power your typical /dev/dsp and /dev/input/mouse and such could be rewritten as kernel-threads that dispatch requests to and from other kernel threads servicing physical hardware in the system you can provide fault-isolation and state reconstruction in the face of crashes without incurring much overhead. Plus user processes could also drive these interfaces directly so user space programs could talk to hardware without needing to load in dangerous, untrusted kernel modules (esp. from closed-source hardware vendors).

Or am I just crazy?

Yeah but microkernels seems like taking things to an extreme that can be accomplished with other means.

Re:A compromise needs to be made.

[Ayanami Rei (621112)]

This is true.
It doesn't necessarily make it less crash prone. But it does make it instrumentable if it proves to be unstable (you could easily trace, debug, intercept, or otherwise validate the requests the blob made if so needed).

Furthermore, the kernel mode portion would merely be relaying commands to trusted memory-mapped regions and IO space requested by the process initially (limited by configuration files, perhaps). Most kernel crashes are the cause of errors (pointer mistakes, buf overflow, race condition, etc.) in the complex driver code which "trap" the system in kernel space. The user space portion would likely instead SIG11 and die... if it left the hardware in a weird state it could be fixed by simply restarting the driver program which would, at its outset, send RESET type commands to the device putting it in a known state.

The largest problem I see is that it isn't possible to easily recast a userspace driver program into a device node without a mechanism like FUSE. It only works if the hardware target in question is nearly always accessed behind a userspace library (OpenGL, libalsa/libjack/OpenAL, libusb).

Proof is in the pudding

[Hacksaw (3678)]

I won't claim that Professor T is wrong, but the proof is in the pudding. If he could produce a kernel set up with all the bells and whistles of Linux, which is the same speed and demonstrably more secure, I'd use it.

But most design is about tradoffs, and it seems like the tradeoff with microkernels is compartmentalism vs. speed. Frankly, most people would rather have speed, unless the security situation is just untenable. So far it's been acceptable to a lot of people using Linux.

Notably, if security is of higher import than speed, people don't reach for micro-kernels, they reach for things like OpenBSD, itself a monolithic kernel.

Re:Proof is in the pudding

[WindBourne (631190)]

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.

Re:Proof is in the pudding

[polemistes (739905)]

You mean: "If you don't eat your meat, you can't have any pudding. How can you have any pudding if you don't eat your meat?"

Hindsight is 20/20

[youknowmewell (754551)]

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."

This has always bugged me about this argument

[joshv (13017)]

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.

Restarting drivers

[Sits (117492)]

I'm going to weigh in over here mainly becuase my quiet slumber in the minix newsgroup has been disturbed by a call to arms from ast [google.co.uk] to correct some of the FUD here on Slashdot.

Drivers have measurably more bugs in them than other parts of the kernel. This has been shown by many studies (see the third reference in the article). This can also been shown empirically - modern versions of Windows are often fine until a buggy driver gets on to them and destablises things. Drivers are so bad that XP even warns you about drivers that haven't been through checks. Saying people should be careful just doesn't cut it and is akin to saying people were more careful in the days of multitasking without protected memory. Maybe they were but some program errors slipped through anyway, bringing down the whole OS when I used AmigaOS (or Windows 95). These days, if my my web browser misbehaves at least it doesn't take my word processor with it, losing the web browser is pain enough.

In all probability you would know that a driver had to be restarted because there's a good chance its previous state had to be wiped away. However a driver that can be safely restarted is better than a driver that locks up everything that touches it (ever had an unkillable process stuck in the D state? That's probably due to a driver getting stuck). You might be even able to do a safe shutdown and lose less work. From a debugging point of view I prefer not having to reboot the machine to restart the entire kernel when driver goes south - it makes inspection of the problem easier.

(Just to prove that I do use Minix though I shall say that killing the network driver results in a kernel panic which is a bit of a shame. Apparently the state is too complex to recover from but perhaps this will be corrected in the future).

At the end of the day it would be better if people didn't make mistakes but since they do it is wise to take steps to mitigate the damage.

Less a comeback than hardware has caught up

[Junks Jerzey (54586)]

Lots of big ideas in programming get pooh-poohed for being too resource intensive (a.k.a. big and slow), but eventually we look back and think how silly we were to be worried about such details, and that of course we should go with the cleaner, more reliable option. Some examples:

zbuffering - go back to any book from the 1970s, and it sounds like a pipe dream (more memory needed for a high-res zbuffer than in entire computer systems of the time)

Lisp, Prolog, and other high-level languages on home computers - these are fast and safe options, but were comically bloated on typical hardware of 20 years ago.

Operating systems not written in assembly language - lots of people never expected to see the day.

Cue the peanut gallery.

[Inoshiro (71693)]

Slashdot may be news for nerds, but it has a serious drawback when it comes to things such as this. The drawback is that what is accepted as "fact" by most people is never questioned.

"Fact": Micorkernel systems perform poorly due to message passing overhead.

Fact: Mach performs poorly due to message passing overhead. L3, L4, hybridized kernels (NT executive, XNU), K42, etc, do not.

"Fact": Micorkernel systems perform poorly in general.

Fact: OpenBSD (monolithic kernel) performs worse than MacOS X (microkernel) on comparable hardware! Go download lmbench and do some testing of the VFS layer.

Within the size of L1 cache, your speed is determined by how quickly your cache will fill. Within L2, it's how effecient your algorithm is (do you invalidate too many cache lines?) -- smaller sections of kernel code are a win here, as much as good algorithms are a win here. Outside of L2 (anything over 512k on my Athlon64), throughput of common operations is limited by how fast the RAM is -- not IPC throughput. Most microkernel overhead is a constant value -- if your Linux kernel us O(n) or O(1), then it's possible to tune the microkernel to be O(n+k) or O(1+k) for the equivalent operations. The faster your hardware, the smaller this value of k since it's a constant value. L4Linux was 4-5% slower than "pure" Linux in 1997 (See L4Linux site for the PDF of the paper [l4linux.org]).

But none of this is something the average slashdotter will do. No, I see lots of comments such as "micorkernels suck!" already at +4 and +5. Just because Mach set back microkernel research by about 20 years, doesn't mean that all micorkernels suck.

Re:Cue the peanut gallery.

[galvanash (631838)]

Do you actually want people to take you seriously when you post utter shit like this?

Fact: Mach performs poorly due to message passing overhead. L3, L4, hybridized kernels (NT executive, XNU), K42, etc, do not.

That is a veiled lie. Mach performed very poorly mostly because of message _validation_, not message passing (although it was pretty slow at that too). I.e. it spent alot of cycles making sure messages were correct. L3/L4 and K42 simple dont do any validation, they leave it up to the user code. In other words once you put back the validation in userland that Mach had in kernelspace, things are a bit more even. And for the love of god NT is NOT a microkernel. It never was a microkernel. And stop using the term "hybrid", all hybrid means is that the marketing dept. wanted people to think it was a microkernel...

Now I will throw a few "facts" at you. It is possible with alot of clever trickery to simulate message passing using zero-copy shared memory (this is what L3/L4/K42/QNX/etc... any microkernel wanting to do message passing quickly). And if done correctly it CAN perform in the same league as monolithic code for many things where the paradigm is a good fit. But there are ALWAYS situations where it is going to be desirable for seperate parts of an OS to directly touch the same memory in a cooperative manner, and when this is the case a microkernel just gets in your damn way...

Fact: OpenBSD (monolithic kernel) performs worse than MacOS X (microkernel) on comparable hardware! Go download lmbench and do some testing of the VFS layer.

Ok... Two things. OpenBSD is pretty much the slowest of all BSD derivitives (which is fine, those guys are more concerned with other aspects of the system and its users are as well), so using it in this comparison shows an obvious bias on your part... Secondly, and please listen very closely because this bullshit needs to stop already, !!OSX IS NOT A MICROKERNEL!! It is a monolithic kernel. Yes it is based on Mach, just like mkLinux was (which also was not a microkernel). Lets get something straight here, being based on Mach doesnt make your kernel a microkernel, it just makes it slow. If you compile away the message passing and implement your drivers in kernel space, then you DO NOT have a microkernel anymore.

So what you actually said in your post could be re-written like this:

Fact: OSX is sooooo slow that the only thing it is faster than is OpenBSD. And you cant even blame its slowness on it being a microkernel. How pathetic... Wow, that says it all in my book :)

And no, you dont have to believe me... Please read this [usenix.org] before bothering to reply.

driver banishment

[bperkins (12056)]

What I'd like to see is a compromise.

There are quite a few drivers out there to support weird hardware (like webcams and such) that are just not fully stable. It would be nice to be able to choose that a driver be run in kernel mode, at full speed, or in a sort of DMZ with reduced performance. This could also make it easier to reverse engineer non-GPL kernel drivers, as well facilitate driver development.

Hurd in Google's summer-of-code

[Spy der Mann (805235)]

I read their "what's new" [gnu.org] and they're participating in Google's Summer of Code.

27 April 2006

        The GNU Hurd project will participate in this year's Google Summer of Code, under the aegis of the GNU project.

        The following is a list of items you might want to work on. If you want to modify or extend these tasks or have your own ideas what to work on, please feel invited to contact us on the bug-hurd mailing list or the #hurd IRC channel.

                * Make GNU Mach use more up to date device drivers.
                * Work on GNU Mach's IPC / VM system.
                * Design and implement a sound system.
                * Transition the Hurd libraries and servers from cthreads to pthreads.
                * Find and implement a reasonable way to make the Hurd servers use syslog.
                * Design and implement libchannel, a library for streams.
                * Rewrite pfinet, our interface to the IPv4 world.
                * Implement and make the Hurd properly use extended attributes.
                * Design / implement / enhance support for the...
                            o Andrew File System (AFS);
                            o NFS client and NFSd;
                            o EXT3 file system;
                            o Logical Volume Manager (LVM).

        Please see the page GNU guidelines for Summer of Code projects about how to make an application and Summer of Code project ideas list for a list of tasks for various GNU projects and information about about how to submit your own ideas for tasks.

What, like VM boundaries are the only way?

[jthill (303417)]

Microkernels are just one way to compartmentalize. Compartmentalization is good, yadda yadda momncherrypie yadda. We've known this for what, 20 years? 30? 40? Nobody suspects it's a fad anymore. The kinds of faults VM isolation guards against aren't the kinds of faults that worry people so much today. Panics and bluescreens aren't solved, but they're down in the background noise. Experience and diligence and increasingly good tools have been enough to put them there and will remain enough to keep them there, because the tools are getting better by leaps and bounds.

"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:Feh.

[AKAImBatman (238306)]

It holds no more true in practice today than it did when he started.

WRONG.

Tanenbaum's research is correct, in that a Microkernel architecture is more secure, easier to maintain, and just all around better. The problem is that early Microkernel architectures killed the concept back when most of the OSes we use today were being developed.

What was the key problem with these kernels? Performance. Mach (one of the more popular research OSes) incurred a huge cost in message passing as every message was checked for validity as it was sent. This wouldn't have been *so* bad, but it ended up worse because a variety of flaws in the Mach implementation. There was some attempt to address this in Mach 3, but the project eventually tappered off. Oddly, NeXT (and later Apple) picked up the Mach kernel and used it in their products. Performance was fixed partly through a series of hacks, and partly through raw horsepower.

Beyond that, you might want to read the rest of TFA. Tanenbaum goes over several other concepts that are hot at the moment, include Virtual Machines, Virtualization, and driver protection.

Virtualization

[jefu (53450)]

I suspect that virtualization may well signal the rise of the microkernel (exokernel?) again.

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.

Tanenbaum is wrong, and should know it

[r00t (33219)]

I'm more than a Linux hacker. I actually worked on a commercial microkernel OS.

Kernels don't often crash for reasons related to lack of memory protection. It's quite silly to imagine that memory protection is some magic bullet. Kernel programmers rarely make beginner mistakes like buffer overflows.

Kernels crash from race conditions and deadlocks. Microkernels only make these problems worse. The interaction between "simple" microkernel components gets horribly complex. It's truly mind-bending for microkernel designs that are more interesting than a toy OS like Minux.

Kernels also crash from drivers causing the hardware to do Very Bad Things. The USB driver can DMA a mouse packet right over the scheduler code or page tables, and there isn't a damn thing that memory protection can do about it. CRASH, big time. A driver can put a device into some weird state where it locks up the PCI bus. Say bye-bye to all devices on the bus. A driver can cause a "screaming interrupt", which is where an interrupt is left demanding attention and never gets turned off. That eats 100% CPU. If the motherboard provides a way to stop this, great, but then any device sharing the same interrupt will be dead.

I note that Tanenbaum is trying to sell books. Hmmm. He knows his audience well too: those who can't do, teach. In academia, cute theories win over the ugly truths of the real world.

Re:Tanenbaum is wrong, and should know it

[OwnedByTwoCats (124103)]

Kernels also crash from drivers causing the hardware to do Very Bad Things. The USB driver can DMA a mouse packet right over the scheduler code or page tables, and there isn't a damn thing that memory protection can do about it. CRASH, big time. A driver can put a device into some weird state where it locks up the PCI bus. Say bye-bye

What if the USB driver

• 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

[AKAImBatman (238306)]

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.

Re:Feh.

[AKAImBatman (238306)]

Look a few posts up at the fellow who mentioned the L4 kernel. While the L4 was really too little, too late (all the OSes we use today were written by that time), it managed to prove that Microkernels *can* be speed demons. What they require, however, is a radically different architecture. If you simply attempt to shoehorn a microkernel into existing Unix systems - precisely what Mach did - you're going to run into trouble.

On the other hand, if you architect the system so that it is impossible to pass a bad message, you may find that performance can actually be *increased*. My own preference has always been an OS based on a VM like Java where it is literally impossible to write code that can cross memory barriers. The result would be that the hardware protection of an MMU would be unnecessary, as would the firewall between the kernel and usermode. Performance would increase substantially due to a lack of kernel mode (i.e. Ring 0) interrupts or jumps.

Re:Feh.

[homer_ca (144738)]

You just described the fourth idea in TFA:

The most radical approach comes from an unexpected source--Microsoft Research. In effect, the Microsoft approach discards the concept of an operating system as a single program running in kernel mode plus some collection of user processes running in user mode, and replaces it with a system written in new type-safe languages that do not have all the pointer and other problems associated with C and C++.

Re:Feh.

[LWATCDR (28044)]

"I see people hitting YEARS of up-time with Linux/BSD/Solaris and hell, even win2k machines. "
Are they not upgrading the kernel? I know that Win2K has had some critical updates in the last few years that required a reboot.
Microkernels do have the potential to be easier to secure than monolithic kernels.
In theory a secure system is a secure system. It is possible to make a monolithic kernel as secure as a microkernel, however it will be harder to make a monolithic kernel as secure as a microkernel.
Just like everything else it is a trade off.
Monolithic
Easier to make a hi-performance kernel.
Harder to secure and to test security.

Microkernel.
Easier to make secure and to test security.
Harder to make hi-performance.

There are secure monolithic systems OpenBSD, Linux, Solaris, and Z/OS jump to my mind.
There are fast microkernels. QNX is a very nice system.

I really like the idea of a microkernel OS. I will try out the first stable, useful OSS Microkernel OS that I find.

Re:Feh.

[Chris Burke (6130)]

I'm very skeptical of this. It would seem to me, at a fundamental level, that a microkernel architecture is simply a heavily reduced kernel with most accepted kernel functions now delegated to external "programs", and a high level of trust is now placed in each and every one of these programs. I can't see how this is good for security.

Well, trust is placed in those user-land programs to perform the task for which they are responsible. Whereas in a monolithic kernel, trust is placed in each subsystem to not only perform the task it is responsible for, but also not to muck with the workings of every other subsystem in the kernel as they all reside in the same address space. Therefore in a microkernel you can have a bug in your network stack without compromising your file system driver or authentication module, while this isn't necessarily true in a macrokernel. Compartmentalization is very good for security.

Which is just one of the reasons Mach is so popular as a research OS, despite never seeing any success in the real world. Compartmentalization also makes the OS easier to maintain, easier to understand, and easier to make modifications for. Plus it's very easy to port to new hardware, if that's required.

In a sense, most OSes are "microkerneled" anyway. Most functionality is implemented by programs running on top of the kernel, which pass messages back and forth between themselves and the kernel. Perhaps my view on this is a little naive, but I don't see too much of a difference between a microkernel module and any other process on the machine.

I think you underestimate the things that are handled by the kernel? Unix uses many user-land services, but also has many services integrated into the kernel. Take the concept of moving functionality into user space to the limit, and you have a microkernel. Your last observation isn't naive, it's correct: a microkernel module isn't necessarily any different than any other process on your machine.

Re:Feh.

[aristotle-dude (626586)]

Yeah really. These tests were already debunked pretty much on the net already. I'm surprised people keep on quoting their "tests" for trolling purposes.

There were several flaws in their tests:
1. They used GCC 3.x compiler instead of GCC 4.x compiler shipping with Tiger because the linux distros they were comparing against had not updated to 4.x of GCC yet.
2. They did not include the OS X specific patches to alter the threading mechanism. This caused a significant performance hit as MySQL was written for the linux threading model rather than a Mach one or more generic model.
3. Binary builds with OS X specific patches were available for download via links from the official sites. There was no need to compile a crippled version.
4. They should have also tested the free/evaluation versions of Oracle as there are optimized version available for both linux and OS X. Assuming this was not a test of only OSS but rather performance as a "server", I do not see why they did not include it.

Not entirely accurate

[WindBourne (631190)]

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.

Titanic

[PIPBoy3000 (619296)]

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?

Re:NT4

[segedunum (883035)]

NT4 had a microkernel whose sole purpose was object brokering.

Well, I wouldn't call NT's kernel a microkernel in any way for the very reason that it was not truly compartmentalised and the house could still be brought very much down - quadruply so in the case of NT 4. You could call it a hybrid, but that's like saying someone is a little bit pregnant. You either are or you're not.

QNX !

[alexhs (877055)]

I have yet to see a "proper" non-academic microkernel which lets one part fail while the rest remain.

QNX [qnx.com], but it isn't open source.

VxWorks [windriver.com] and a few other would also fit.

Re:multicompartment isolation

[LurkerXXX (667952)]

BeOS didn't seem slow to me. No matter what I threw at it.

Re:multicompartment isolation

[gEvil (beta) (945888)]

So wait a second. In your analogy, which part of Linux plays the Leonardo DiCaprio role? (I'm curious to know which part of Linux I should take out back and kick repeatedly.)

A false dichotomy

[The Conductor (758639)]

I seem to find this microkernel vs. monolithic argument a bit a of a false dichotomy. Micorkernels are just at one end of a modularity vs. $other_goal trade-off. There are a thousand steps in-between. So we see implementations (like the Amiga for example) that are almost microkernels, at which the purists shout objections (the Amiga permits interrupt handlers that bypass the OS-supplied services, for example). We also see utter kludges (Windows for example) improve their modularity as backwards compatibility and monopolizing marketing tactics permit (not much, but you have to say things have improved since Win3.1).

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:How hard...

[iabervon (1971)]

This is actually sort of happening. Recent work has increased the number of features that can be provided in userspace. Of course, this is done very differently from how a traditional microkernel does it; the kernel is providing virtual features, which can be implemented in user space. For example, the kernel has the "virtual file system", which handles all of the system calls, to the point where a call to the actual filesystem is needed (if the cache, which the VFS handles, is not sufficient). The actual calls may be made to userspace, which is a bit slow, but it doesn't matter, because it's going to wait for disk access anyway.

The current state is that Linux is essentially coming around to a microkernel view, but not the classic microkernel approach. And the new idea is not one that could easily grow out of a classic microkernel, but one that grows naturally out of having a macrokernel but wanting to push bug-prone code out of it.

Re:Oh Dear

[igb (28052)]

It's tempting for people who work in fields where performance matters to assume it matters for everyone, all the time. Do I need my big-iron Oracle boxes to be quick? Yes, I do, which is why they are Solaris boxes with all mod cons. Do I need the GUI on my desk to be pleasant to use? Yes, which is why it's increasingly a Mac that I turn to first. Sure, a G4 Mac Mini isn't quick. But there's a room full of Niagaras, Galaxies and 16-way Sparc machines to do `quick' for me.

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

OS X - First make it work, then make it fast

[alispguru (72689)]

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.

QNX for teh win :)

[WinPimp2K (301497)]

Not only does the "Q" stand for "Quick", but when Quantum Software Systems Ltd (now know as QNX) first released their "microkernal", 'message passing", "real time" OS for the 8086 processor in the early 80's they called it "QUNIX". After a brief discussion with AT&T's legal staff, they determined that the vowels were way too expensive and renamed it to "QNX". The microkernal took up less than 64K.

Unlike certain other OS's, QNX is used in control applications with life and death implications. (nuclear reactors and medical equipment for example)

QNX has been through a lot of changes since then. And I have not kept up with most of them. I do know that as of a few years ago they did make a "free for personal use" release that included their development system. And a few years before that, they had a 1.44meg demo disk that had their entire OS, GUI and web browser on it.

But don't take my word for it go check out their website.

Re:Metaphors eh?

[misleb (129952)]

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

Re:Metaphors eh?

[AKAImBatman (238306)]

Methinks a better analogy is: Snap your timing chain on a high performance engine and watch the entire machine tear itself into a piece of junk. Snap a belt or two on a more pedestrian engine and watch it stop until the belt is replaced.

Re:O Tanenbaum...

[cbiltcliffe (186293)]

O Tanenbaum, O Tanenbaum
Your microk3rn3l rul3z!
O Tanenbaum, O Tanenbaum
Those m0n0lithic foolz!
They build a kernel all-in-one,
Where all the bugs can have free run.
O Tanenbaum, O Tanenbaum
Those Linux guys just drool. ;)