6 ms·

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

46 points by vezzy-fnord 11y ago

smosher_ 11y ago
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 11y ago
  This sounds kind of like an exo kernel?
  - duaneb 11y ago
    The exo kernel typically implies a larger, secondary kernel for less performance-oriented operations. This just seems like a straight-up microkernel.
KMag 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      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. ;)
Sanddancer 11y ago
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 11y ago
  Glad they're adding that.
nickpsecurity 11y ago
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.

46 points by vezzy-fnord 11y ago

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 11y ago
This sounds kind of like an exo kernel?
- duaneb 11y ago
  The exo kernel typically implies a larger, secondary kernel for less performance-oriented operations. This just seems like a straight-up microkernel.

KMag 11y ago

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 11y ago
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 11y ago
  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 11y ago
    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. ;)

Sanddancer 11y ago

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 11y ago
Glad they're adding that.

nickpsecurity 11y ago

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.