This 6k vs 6M LoC comparison is pretty dubious. If your disk driver has a bug and overwrites some data you're just as screwed up, be it running in userspace or kernel space. The argument these bugs are less powerful because they are now in userspace "can't do very much" is at best limited. Drivers can screw up hardware just as easily, filesystems can screw up your data just as easily, etc. The memory grant stuff seems interesting though and I see how that can protect you from some forms of memory corruption.
Running all these processes in userspace seems to gain you some capabilities to more easily respawn/reset drivers. Live upgrade seems exciting. I wonder if you are paying for that in added complexity that is hard to debug. The tests they did are simulating basically hardware errors, and it does seems to be quite resilient to those. In practice I fear the software bugs more. The bugs I actually see in Linux tend to be oopses generated by bad code that simply disable the driver. The bad ones screw up the hardware they are controlling and require a reboot. It is unclear in these situations that the driver can be correctly reset without resetting the hardware too.
I wonder how much of this respawn/update functionality you can apply easily to a Linux kernel right now. Most drivers and filesystems can already be built as modules and loaded/unloaded in a live kernel. I wonder how much that can be extended.
This 6k vs 6M LoC comparison is pretty dubious. If your disk driver has a bug and overwrites some data you're just as screwed up, be it running in userspace or kernel space. The argument these bugs are less powerful because they are now in userspace "can't do very much" is at best limited
They are less powerful in user-space he states this about 25 minutes into the talk "moving bugs to user-space will do less damage"...roughly.This is true instead of getting full ring0 access to anything I can only do what the driver is allowed to do if I exploit a bug in the driver.
Running all these processes in userspace seems to gain you some capabilities to more easily respawn/reset drivers. Live upgrade seems exciting. I wonder if you are paying for that in added complexity that is hard to debug
Why would there be added complexity? Linux has an api just as well but less defined than simple ipc - even more complex. Hard to debug? you do understand that having parts of the kernel in userspace makes it easier to debug
The bugs I actually see in Linux tend to be oopses generated by bad code that simply disable the driver.
Read LWN theres roughly a root exploit every 2 weeks
An ideal operating system would be a sort of exokernel but proven and a 'relaxed' api that would allow distributed computing. Unverified applications would run under a vm with proven parts being compiled as well as compiling heuristically verified parts and jitting the other needed parts.
>They are less powerful in user-space he states this about 25 minutes into the talk "moving bugs to user-space will do less damage"...roughly.This is true instead of getting full ring0 access to anything I can only do what the driver is allowed to do if I exploit a bug in the driver.
I did listen to the talk and that justification. That's why I said it was pretty limited. That may be true for security bugs in drivers. For a network driver that may even be very important. In practice what I see is that the actual bugs I care about in Linux drivers are code bugs that disable the device, or in a filesystem cause disk corruption. None of those are solved by a microkernel. Microkernels give you a bunch of provable advantages in areas that monolithic kernels don't seem to do too badly at.
>Why would there be added complexity? Linux has an api just as well but less defined than simple ipc - even more complex.
This is anything but simple IPC. You're sending async messages around and wanting to handle restart of whole pieces and reissuing of commands. It is much more complex and with many more edge cases that the equivalent Linux call stack.
>Hard to debug? you do understand that having parts of the kernel in userspace makes it easier to debug
Because now you're trying to restart a driver for a device that is in an unknown state and then restarting the operation of the filesystem accessing the driver that now has to make sure its operations are idempotent otherwise it will screw up. The number of new edge cases is immense. It could get hairy really fast. That is even touched upon in the presentation with the async messaging and deadlock avoidance. That's why it's harder to debug. Because you're adding a bunch of complex code in error handling paths that get executed once in a blue moon.
>Read LWN theres roughly a root exploit every 2 weeks
I read LWN every week, there are some local root exploits once in a while. The memory protection stuff could be good for that and you could implement it in Linux if you wanted. I specifically stated that part is interesting for this. My point is that the non-security bugs I care about wouldn't be prevented by this technique.
Exactly. Linux is also useful enough to run the laptop Tannenbaum's presentation is running on while no version of Minix is. (He's running windows, but it could have been Linux)
Minix drivers would still have to exist, and to be usable, they still need access to hardware. There's no presented reason why Minix drivers should have fewer bugs / LoC than linux, except that individual drivers can't take down other "kernel" processes.
That might get you minor improvements in reliability, but it won't fix this issue of bugs existing in hardware drivers in the first place.
IMO, the way forward in reliability is a kernel written in a more correct, more expressive (haskell-ish) Programming Language.
> There's no presented reason why Minix drivers should have fewer bugs / LoC than linux
On a monolithic kernel, each and every driver is aware (or at least can be) of each and every other driver linked into the kernel. It may create added complexities that should be absent and abstracted in microkernel-based OSs.
Microkernels are not a silver bullet and buggy drivers will be able to put the system - buses, coprocessors, whatever - in weird states that can hang or crash the machine.
I like the idea of parameter validation on every function. That and extensive unit tests built into the kernel. Tests could be invoked on boot with a specific switch and the kernel would perform a self-test (with crash detection) before bringing up your system. This could help find hardware incompatibilities and other weird defects that could affect reliability of the whole box.
I don't think we would need a Haskell-like language. You can do very Haskell-ish things in C. All it takes is lots of discipline (just as much as writing Haskell)
Maybe forcing kernel developers to learn Haskell would help ;-)
I've never found that writing Haskell demanded much discipline at all, just follow a few simple rules (like making total functions etc.), and your code is well on the way to doing exactly what you think it should.
What I'm hearing is "It helps make things more stable, yes, but doesn't solve everything, so why bother?". The advantages Minix has to offer doesn't solve every problem, least of all the wetware problem that there will always be bugs. But if you're after a high reliability system, say a plane, you don't want a bug in the audio driver making the navigation systems crash. Who cares if the warning signals sound a little weird for a second, if the system is still running correctly, apart from the audio?
The less that is tied into the kernel, the less can crash the system easily. The disk driver could certainly overwrite the kernel on disk, and that could be... pretty bad, but no system that doesn't in some way verify that the code is correct can ever protect against this sort of programmer caused bug.
It should also be noted that Minix isn't exactly aimed as a replacement for linux, and I'm not one hundred percent sure that making such a comparison is that useful.
Running all these processes in userspace seems to gain you some capabilities to more easily respawn/reset drivers. Live upgrade seems exciting. I wonder if you are paying for that in added complexity that is hard to debug. The tests they did are simulating basically hardware errors, and it does seems to be quite resilient to those. In practice I fear the software bugs more. The bugs I actually see in Linux tend to be oopses generated by bad code that simply disable the driver. The bad ones screw up the hardware they are controlling and require a reboot. It is unclear in these situations that the driver can be correctly reset without resetting the hardware too.
I wonder how much of this respawn/update functionality you can apply easily to a Linux kernel right now. Most drivers and filesystems can already be built as modules and loaded/unloaded in a live kernel. I wonder how much that can be extended.