

Construction of a Highly Dependable Operating System (2006) [pdf] - vezzy-fnord
https://www.cs.vu.nl/~ast/publications/edcc-2006.pdf

======
Sanddancer
I'm glad AST has restarted the Minix project. It's a great little kernel that
deserves much more attention. One of the bits of research that could allow for
many more interesting things is use of the IOMMU for drivers [1]. The given
paper unfortunately does not give benchmarks, but I imagine that it's an area
that you could see some rather sizable performance benefits in a microkernel-
style system; with an IOMMU, there could potentially be zero context switches
in an app's access of a resource, which could lead to even less CPU overhead
than a monolithic kernel could be capable of.

[1] [http://www.minix3.org/docs/szekeres-
iommu.pdf](http://www.minix3.org/docs/szekeres-iommu.pdf)

~~~
nickpsecurity
Glad they're adding that.

------
smosher_
In case anyone is wondering which project this is:

    
    
        The concrete contribution of the research report here
        is the design and implementation of a fully compartmen-
        talized operating system, MINIX 3. To properly isolate
        faults, we have removed all drivers from the kernel and
        run them as separate, unprivileged user-mode processes,
        protected by the MMU hardware. Since all servers also
        run in user mode in our design, only a tiny microker-
        nel that does not contain any foreign, untrusted code is
        left in kernel mode. Each component has only the mini-
        mum privileges it needs in order to prevent failures from
        spreading. In our design, driver failures are no longer
        fatal and do not require rebooting the computer.

~~~
sown
This sounds kind of like an exo kernel?

~~~
duaneb
The exo kernel typically implies a larger, secondary kernel for less
performance-oriented operations.

This just seems like a straight-up microkernel.

------
KMag
Are any of you running MINIX 3 as your daily driver?

For about 6 months in university, I quad-booted Linux, Windows, BeOS, and QNX.
I remember regularly waking up and finding that my BeOS ethernet driver had
crashed overnight. The fix was clicking "Ok" to restart the driver. Of course
it would be nice to have a better ethernet drier, but it was nice that a
driver crash didn't bring down the system.

Conversely, I have a corrupted CD-R that causes kernel panics in Win2k, and
circa 2004 releases of Linux and OS X. At least drivers for consumer printers,
ISO 9660, and CD/DVD drives should be in userspace, even on hybrid/monolithic
kernel systems. These aren't performance-critical devices.

A hard realtime microkernel should give you the isolation abilities of a
hypervisor with overhead near that of LXC containers. For applications like
HFT, you could make one of your ethernet cards use a driver that's a library
running inside your performance-critical application, giving you performance
near that of running your code in-kernel. I'm hoping the current
containerization push brings more attention to microkernel research.

~~~
brianclements
As a long time *nix hobbyist user, I can't help but notice how
containerization is starting to essentially provide microkernel-like os design
patterns using the more mature Linux kernel instead of starting from scratch.
I'm curious what everyone thinks about whether the containerization approach,
at its best, like with projects like rancherOS (I'm guessing), can compete
with a the theoretical strengths of a microkernel?

~~~
vezzy-fnord
Absolutely not.

They have nothing in common.

You're still running a monolithic kernel with all drivers and subsystems
running in kernel space. The only thing OS-level virtualization like
containers gives you here is that a limited amount of subsystems can be
multiplexed into independent logical domains (all still running a full OS
instance, mind you) on a single host.

You don't get any of the reliability or flexibility gains.

Actual examples of microkernel patterns in Linux are, and I quote from my Hurd
cross-toolchain article [1]:

    
    
       It’s also worth noting that several more recent
       developments in Linux like kdbus (which was called 
       “neutered Mach IPC” by Neal Walfield), the “tinification”
       effort [http://tiny.wiki.kernel.org], FUSE, NSUSE, the
       MADV_USERFAULT flag in madvise(2), kmscon and other 
       userland VT subsystems, have demonstrated that there is
       in fact user demand for microkernel-like features in
       Linux, whether people realize this directly or not. It
       is not unthinkable to conceive of Linux (particularly
       with systemd) growing into a hybrid kernel approach with
       certain low-level subsystems adequately usable from a
       user context.
    

Again, these are all highly limited. But that is the direction Linux is mostly
heading -- a bad hybrid kernel.

[1]
[http://blog.darknedgy.net/technology/2015/07/25/0/](http://blog.darknedgy.net/technology/2015/07/25/0/)

~~~
nickpsecurity
Yeah, they're slowly reinventing microkernel concepts in a pretty heavy-weight
way. However, don't discount the recent efforts in containerization. They
might not be learning the main lesson but they're certainly copying (and
benefiting from) pieces of it. Maybe they'll get there one day. ;)

~~~
XorNot
The smugness of this comment is unwarranted. Linux became a practical OS which
runs everything from toasters to spaceships. The 'obvious superiority' of
microkernels has failed to be borne out since their inception way back when it
was first written. And the success of small parts of the idea within Linux
does not implicitly prove that the idea is actually practical or performant as
imagined.

Implementation details are everything and not always solvable.

~~~
vezzy-fnord
The obvious superiority of microkernels is seen in the invisible ubiquity of
QNX and L4 throughout the industry. There's probably more L4 deployments than
Linux, in hardware like baseband processors.

The most common OS then is probably not Linux, but TRON. It's real-time, but
I'm not sure if it's a u-kernel. Nonetheless, RTOS in general is well served
by u-kernels.

~~~
nickpsecurity
Supporting your point, OK Labs claimed years ago their OKL4 microkernel had
hit a billion units in phone market. Mainly for baseband isolation and legacy
code (eg brew). So, it's exceeded Linux servers and slowly catching up to
Android esp as it runs it virtualized.

And Samsung Galaxies use INTEGRITY Multivisor for Knox. Blackberry plus
automotive often do QNX. Apple does a hybrid with Mach and wants a real one. A
lot of design moving one way in particular. ;)

~~~
vezzy-fnord
_Apple does a hybrid with Mach and wants a real one._

I know that XNU is based on a chimera between OSF Mach and FreeBSD, but I'm
pretty sure most practical u-kernel gains are lost in this process. They do
have the basic resources like tasks, threads, VM and IPC with its system of
port rights checking, but it's mostly leveraged as a convenient abstraction at
best. I don't think OS X even supports per-application default memory
managers, does it?

However, what you said about "wants a real one" really piqued my interest. Is
it true Apple is researching pure microkernel designs for their products? That
sounds great, do share some links.

~~~
nickpsecurity
Yeah, that and some basic functions are all they use it for. A write up way
back indicated they though Mach was a mistake. So, the alternatives were a
better microkernel or full monolithic. One unofficial project tried to port it
to L4. Not sure what Apple's stance is under Tim Cook, though.

------
nickpsecurity
It was a really good read back when I had it. The MINIX 3 project made many
interesting design decisions to support the paper's goals. I'm curious: has
anyone benchmarked the reliability of any servers running on MINIX 3 over past
year or so? Wondering how much it delivers so far.

