L4 microkernels: The lessons from 20 years of research and deployment
The paper doesn't mention QNX at all. QNX is similar to early L4, but they've taken slightly different paths.<p>L4 got rid of "long message passing", in favor of shared memory and interrupt-like IPC. This is great for the kernel - no copying delays and no buffering problems.  But it means that communicating processes have to share some memory pages and cooperate properly.  If the shared memory page is something like a chain of linked buffers, one side may be able to screw up the other side.  If that's how you talk to the file system, it may be possible to attack the file system process that way.  This won't crash the kernel.<p>Because L4's API is so limited, it's used mostly as a VM, with the usual bloated Linux kernel on top.  QNX has only a few more kernel features than modern L4, but it can implement the POSIX API with just support in the C library.  When you call "write()" from C/C++ in QNX, the C library makes a MsgSend request which is directed to a file system service, device service, or network service. The code for this is tiny.  When you call "write()" from C/C++ on L4, you're usually just making a Linux system call to an ordinary big Linux in a VM. Eventually that Linux talks to other processes which do the physical disk I/O. The problem is that the giant Linux kernel is still there, just a bit more isolated from the hardware.  The total amount of code that can break has not been reduced significantly.