Construction of a Highly Dependable Operating System (2006) [pdf] | Hacker News Reader

Construction of a Highly Dependable Operating System (2006) [pdf]

cs.vu.nl

46 pointsvezzy-fnord18 comments

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

Glad they're adding that.

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.

This sounds kind of like an exo kernel?

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

This just seems like a straight-up microkernel.

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.

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?

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/

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. ;)

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.

DOS did something similar back in the day and a desktop was even built on it. Windows was later the most widely deployed OS with billions of lines of COBOL powering much backend processing. Would you similarly say their architectural superiority is proven by the number of users or platforms?

Those of us who push microkernels do it because they were proven in practice (esp in embedded) for over a decade. Linus's complaints didn't pan out. MINIX 3 achieved in a few years better reliability than Windows or Linux had in nearly their first decade. Driver isolation had a lot to do with that. Anyone worrying about performance should look at the Playbook vs iPad demo they did a while back showcasing QNX microkernel.

Linus was repeatedly warned [1], was smug as heck in replies, his OS is now adopting microkernel-like techniques, and so I call it as he would. More humble than he would, actually. ;)

[1] http://www.cs.vu.nl/~ast/reliable-os/

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.

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. ;)

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.

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.

There is a fuse module for iso9660. Unfortunately, it looks like work stopped on it seven years ago, with its code left to moulder on sourceforge. The hardware driver itself would be a lot more difficult, as the atapi commands that cd/dvd drives require working in the chipset drivers. Plus, the hardware itself is not usually the culprit behind the crashes, so you'd not get much of a reliability boost from it, unless you're willing to have all of your hdd/ssd drive controllers be in userspace as well.

You can already have userspace ethernet drivers on Linux.

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.

Reply on news.ycombinator.com