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."
SE Linux provides security models to compartmentalize your programs and applications and such. This is a completely different beast then compartmentalizing your individual kernel parts. Modules was kind of a primitive step in the direction of a microkernel, but still a long ways off from a technical standpoint.
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
Performance was fixed partly through a series of hacks, and partly through raw horsepower.
O RLY
I have yet to see a "proper" non-academic microkernel which lets one part fail while the rest remain.
QNX, but it isn't open source.
VxWorks and a few other would also fit.
I have discovered a truly marvelous proof of killer sig, which this margin is too narrow to contain.
Mklinux, one of the first versions of linux-for-ppc, had a microkernel architecture. So it's been done, at least for ppc. Mklinux will run on a 10yr old mac. I don't know about newer ppc machines.
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.
You either believe in rational thought or you don't
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.
Live today, because you never know what tomorrow brings
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.
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.
The enemies of Democracy are
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.
Jesus was a compassionate social conservative who called individuals to sin no more.
The goal is to have a system such that you maximize the segregation of the parts. If the SCSI subsystem crashes -- for example -- you flush it and restart it. While it may not be possible to totally isolate every subsystem, with a microkernel subsystems should be more robust than in monolithic kernels.
For all of Linus' scorn of microkernels, Linux borrows heavily from the concept, if not from the theory. One could almost say that Linux implements a microkernel poorly through the kernel module interface. It fails to be a true microkernel in a number of ways, though, not least of which is the low degree to which it isolates modules.
In any case, your nervousness about a system where a "fundamental" subsystem craps out is understandable in someone who's main experience is with monolithic kernels, because the corruption of one subsystem often infects other systems. For example, IME when the Linux SCSI module starts barfing (which happens with distressing regularity), if you're lucky, you can unload and reload the SCSI modules, but eventually, you're going to have to reboot, because it never quite works well after a reload. In a microkernel, subsystems are just services that other subsystems may use, but aren't intimate with. A corruption in one subsystem shouldn't lead to corruptions in any other subsystem.
--- SER
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 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.
Do you actually want people to take you seriously when you post utter shit like this?
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...
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 before bothering to reply.
- sigs are stupid