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."
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.
Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.
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.
Javascript + Nintendo DSi = DSiCade
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.
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. /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).
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
Or am I just crazy?
Yeah but microkernels seems like taking things to an extreme that can be accomplished with other means.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
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.
All the technology in the world won't hide your lack of vision, talent, or understanding.
"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.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
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).
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.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
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.