I think history has proven that this theory: > Better security, better reliability, better modularity. Better security because in a muicrokernel [sic] system a bug in one driver only gives an attacker access to that subsystem (or maybe even that driver), as opposed to having unlimited access to the whole system like is the case with mainstream operating systems today. Better relaibility [sic] becasue [sic] a crash in…
Device drivers as separate processes might not improve much the resistance against intentional exploits, but they would certainly greatly improve the resistance against bugs. There are parts that are so simple that it can be practically guaranteed that they are bug free, e.g. the keyboard driver. Also the microkernel itself can be practically bug-free. A GPU driver is unlikely to ever be bug free, but if the GPU is i…
Maybe we should revisit microkernels
21–30 of 34 posts
Re: Maybe we should revisit microkernels
#22Earlier quoted context omitted.
There exist several microkernels that don't suffer much from overhead, it's not hypothetical but decades old technology, from oldest to newest: QNX, the L4 family, Fuchsia, RedoxOS.
What about Minix 3? Probably the most widely deployed microkernel ever: it's inside every Intel CPU for the last ~20 years. Already has a mostly-working port of the NetBSD userland. It was shaping up quite well until Andy Tanenbaum retired. Since then, nothing. Of course, Intel has never released any of its code, which is terrible -- but legal and license-compliant. https://www.osnews.com/story/136174/minix-is-dead/
Re: Maybe we should revisit microkernels
#23I'm hoping it can become my daily driver.
Re: Maybe we should revisit microkernels
#24I think history has proven that this theory: > Better security, better reliability, better modularity. Better security because in a muicrokernel [sic] system a bug in one driver only gives an attacker access to that subsystem (or maybe even that driver), as opposed to having unlimited access to the whole system like is the case with mainstream operating systems today. Better relaibility [sic] becasue [sic] a crash in…
Device drivers as separate processes might not improve much the resistance against intentional exploits, but they would certainly greatly improve the resistance against bugs. There are parts that are so simple that it can be practically guaranteed that they are bug free, e.g. the keyboard driver. Also the microkernel itself can be practically bug-free. A GPU driver is unlikely to ever be bug free, but if the GPU is i…
Yes, it should be. I can name zero times in the past half-decade that it's been possible to soft-reset the hardware in my GPU.
The "reset the GPU switch" is the power switch on my computer.
That's true of most hardware. If my ethernet, wifi, or whatever else enter an unstable state, on paper, the monolithic kernel can do the same thing as the microkernel: unload the module, then reload the module. In practice, I've virtually never seen a driver able to pick up a piece of hardware in an unstable state and be able to "reset" it.
> With device drivers in separate processes, bugs in one should not corrupt the memory of others, so restarting a device driver should be enough, instead of rebooting the computer.
Device drivers can corrupt other devices easily enough. The hardware itself would need to be built for isolation.
> Any complex program must be designed from the beginning to be easy to test and debug. If the device drivers are distinct processes, there is no reason to be more difficult to debug them. On the contrary, because the interactions between them are more limited than when they live in a common address space, they should be easier to debug.
That's exactly the myth.
In practice, a complex data flow for a heisenbug might start at the network layer, go through the disk, and land on the GPU. Tracing that on a microkernel requires instrumentation which, while possible in theory, I've never seen in practice.
I'd love to see a hardware stack where everything is ECC, devices are isolated, etc. but for now, on a typical computer, plugging in a bad USB device can brick the whole system (regardless of the software on it). The assumption is that devices on your PCIe bus can be trusted.
> This can only make much easier the reasoning about how the entire system works.
You make very strong statements, without support.
There's a reason Linux runs on every Android phone, almost every router, and increasingly, devices like home microwaves.
Re: Maybe we should revisit microkernels
#25I think history has proven that this theory: > Better security, better reliability, better modularity. Better security because in a muicrokernel [sic] system a bug in one driver only gives an attacker access to that subsystem (or maybe even that driver), as opposed to having unlimited access to the whole system like is the case with mainstream operating systems today. Better relaibility [sic] becasue [sic] a crash in…
> history has proven What history? What proof? What evidence? What commercial microkernel systems are you referencing that suffer from trivial LPEs? Or whole system DoS from unprivileged code execution? To the extent that you argue your alleged failure modes are fundamental. > none of the upsides have panned out Again, what history? What proof? What evidence? One of the stated upsides relative to monolithic kernels i…
...
> standard commercial monolithic kernels
Note the path from A to B.
Fully monolithic: Linux, FreeBSD, NetBSD, OpenBSD, Solaris, AIX, zOS.
Mostly monolithic: Windows, MacOS
To get to microkernels, we're reaching for QNX and Minix.
Monolithic kernels won *hard* with good reason.
> critical flight systems
Hard RTOS is a whole different domain of engineering. You're very confused if you think the same principles apply to something which makes sense in a mainstream OS.
Re: Maybe we should revisit microkernels
#26Earlier quoted context omitted.
Device drivers as separate processes might not improve much the resistance against intentional exploits, but they would certainly greatly improve the resistance against bugs. There are parts that are so simple that it can be practically guaranteed that they are bug free, e.g. the keyboard driver. Also the microkernel itself can be practically bug-free. A GPU driver is unlikely to ever be bug free, but if the GPU is i…
> A GPU driver is unlikely to ever be bug free, but if the GPU is in an unstable state, because the keyboard should still be working fine, it should be easy to reset the GPU and continue the work without rebooting the computer. Yes, it should be. I can name zero times in the past half-decade that it's been possible to soft-reset the hardware in my GPU. The "reset the GPU switch" is the power switch on my computer. Th…
Re: Maybe we should revisit microkernels
#27Earlier quoted context omitted.
There exist several microkernels that don't suffer much from overhead, it's not hypothetical but decades old technology, from oldest to newest: QNX, the L4 family, Fuchsia, RedoxOS.
What about Minix 3? Probably the most widely deployed microkernel ever: it's inside every Intel CPU for the last ~20 years. Already has a mostly-working port of the NetBSD userland. It was shaping up quite well until Andy Tanenbaum retired. Since then, nothing. Of course, Intel has never released any of its code, which is terrible -- but legal and license-compliant. https://www.osnews.com/story/136174/minix-is-dead/
Concerning performance: studies suggest that Minix 3 is significantly slower (10 to > 100 times) than L4 and even Linux (see e.g. https://www.cscjournals.org/download/issuearchive/IJE/Volume... or https://www.minix3.org/theses/priescu_thesis_2012.pdf).
Concerning "inside every Intel CPU": we actually don't know which version that was supposed to be and how much it was modified.
Re: Maybe we should revisit microkernels
#28Earlier quoted context omitted.
> history has proven What history? What proof? What evidence? What commercial microkernel systems are you referencing that suffer from trivial LPEs? Or whole system DoS from unprivileged code execution? To the extent that you argue your alleged failure modes are fundamental. > none of the upsides have panned out Again, what history? What proof? What evidence? One of the stated upsides relative to monolithic kernels i…
> What history? What proof? What evidence? ... > standard commercial monolithic kernels Note the path from A to B. Fully monolithic: Linux, FreeBSD, NetBSD, OpenBSD, Solaris, AIX, zOS. Mostly monolithic: Windows, MacOS To get to microkernels, we're reaching for QNX and Minix. Monolithic kernels won *hard* with good reason. > critical flight systems Hard RTOS is a whole different domain of engineering. You're very con…
You claimed that microkernels suffer from the same security problems that plague commercial monolithic kernels such as Linux, Windows, macOS, iOS, Android, etc.
You claimed without evidence, and I quote, “none of the upsides have panned out”.
In contrast, microkernels have completely dominated the field, displacing prior monolithic kernel solutions, in domains where reliability and security are not the lowest priority. All you have really supported is that the broader commercial IT landscape continues to prefer easily hacked systems as long as they can save a buck.
Re: Maybe we should revisit microkernels
#29Earlier quoted context omitted.
> What history? What proof? What evidence? ... > standard commercial monolithic kernels Note the path from A to B. Fully monolithic: Linux, FreeBSD, NetBSD, OpenBSD, Solaris, AIX, zOS. Mostly monolithic: Windows, MacOS To get to microkernels, we're reaching for QNX and Minix. Monolithic kernels won *hard* with good reason. > critical flight systems Hard RTOS is a whole different domain of engineering. You're very con…
You did not claim that microkernels were less commercially successful. You claimed that microkernels suffer from the same security problems that plague commercial monolithic kernels such as Linux, Windows, macOS, iOS, Android, etc. You claimed without evidence, and I quote, “none of the upsides have panned out”. In contrast, microkernels have completely dominated the field, displacing prior monolithic kernel solution…
FYI: For most commercial network equipment (internet backbone and similar), reliability and security are the highest priority. Most of that is Linux, BSD, and friends.
Re: Maybe we should revisit microkernels
#30Earlier quoted context omitted.
> A GPU driver is unlikely to ever be bug free, but if the GPU is in an unstable state, because the keyboard should still be working fine, it should be easy to reset the GPU and continue the work without rebooting the computer. Yes, it should be. I can name zero times in the past half-decade that it's been possible to soft-reset the hardware in my GPU. The "reset the GPU switch" is the power switch on my computer. Th…
I think Windows is capable of resetting the GPU and its driver without a hard reboot, actually. At least in theory.
This was possible with old-school graphics cards in the nineties and early 00's, when they were mostly a framebuffer, with a bit of 2d acceleration.