| ▲ | frognumber 2 days ago |
| 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 one subsystem only crashes that subsystem instead of crashing everything; if windows were a microkernel system then the crowdstrike bug would have just stopped some IT security staff from getting telemetry instead of being front page news. If linux were a microkernel system then the linux kernel team wouldn't be responsible for merging every driver for every hardware device, and wouldn't be responsible for vetting code that they would have to become experts on the inner workings of every chip supported by the linux kernel to properly vet. Is false. In particular: - A kernel-level exploit can almost always be escalated. If I control your filesystem, you're SOL - A kernel-level crash in any subsystem brings down the whole system. If your file system crashes, or your GPU is in an unstable state, there is no coming back - Modularity is a question of clear boundaries. Whether those are static linking, dynamic linking, or XML-RPC doesn't change the level of modularity. And so on. Basically, none of the upsides have panned out. On the other hand, code complexity explodes. Microservices need to know who to call how. The whole "a crash in one subsystem only crashes that subsystem instead of crashing everything" means every subsystem needs defensive code for things going wrong elsewhere. KLOCs go up, bugs/KLOC stay constant, and things get less stable. Plus, it's hard to reason about systemically, and without excellent telemetry, neigh-impossible to debug. |
|
| ▲ | Veserv a day ago | parent | next [-] |
| > 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 is superior reliability. There are numerous microkernels reliable enough for usage in critical flight systems. None of the standard commercial monolithic kernels are even in the vicinity of that. Another of the stated upsides is superior security. There are multiple microkernels secure enough to be platforms for systems that need to be secure against state actors. None of the standard commercial monolithic kernels are even in the vicinity of that. History has proven the opposite of your claims. The concrete evidence is the opposite of your vague unsupported assertions. |
| |
| ▲ | frognumber 19 hours ago | parent [-] | | > 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 confused if you think the same principles apply to something which makes sense in a mainstream OS. | | |
| ▲ | Veserv 10 hours ago | parent [-] | | 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 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. | | |
| ▲ | frognumber 7 hours ago | parent [-] | | You claimed without evidence, or more accurately, bad evidence, confusing RTOS with "reliability and security." And you were somehow confused that security mattered for systems with no network connection. 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. | | |
| ▲ | Veserv 6 hours ago | parent [-] | | > You claimed without evidence, or more accurately, bad evidence, confusing RTOS with "reliability and security." That sentence is grammatical nonsense. Try again to articulate your point so it is coherent. Furthermore, you have still failed to present any historical examples for literally any of your bullet points or articulate any of the claimed upsides you purport have failed to pan out. In contrast, I have pointed out two frequently claimed upsides, reliability and security, that have demonstrably succeeded to such a degree that prevailing monolithic systems were largely replaced with microkernel systems in domains where reliability and security are highly valued such as aerospace and defense. To the extent that monolithic systems are still used, they were either the legacy option that has not been replaced or chosen where cost reduction is the highest priority, not security and reliability. > FYI: For most commercial network equipment (internet backbone and similar), reliability and security are the highest priority. Frankly, I find it baffling that you think that nuclear weapon systems, military jet fighters (which are network connected by the way), and commercial jetliners (also network connected) have lower reliability and security requirements than commercial networking equipment. And this is ignoring the fact that commercial networking equipment is some of the worst with respect to reliability and security. Cisco, one of the largest vendors in the space, routinely has trivial remote authentication bypasses allowing complete takeover. Here is one from last month: https://app.opencve.io/cve/CVE-2026-20181. One from earlier this year: https://app.opencve.io/cve/CVE-2026-20079. Or this one: https://app.opencve.io/cve/CVE-2026-20127. How about this one: https://app.opencve.io/cve/CVE-2026-20182. Commercial networking equipment security is a joke. Find me literally any technical person who would claim that Cisco can defend against state actors. I will wait. |
|
|
|
|
|
| ▲ | move-on-by a day ago | parent | prev | next [-] |
| I can’t say I know much about kernels, but what you say rings true. It’s not unlike the micro service vs monolith argument. It depends on the use cases, but in a system where the micro services depend on each other, all you have is a distributed monolith. All the complexity and overhead, and none of the benefits. Keep dependencies close. |
|
| ▲ | adrian_b 2 days ago | parent | prev | next [-] |
| 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 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. On Linux I have seen cases when the GPU crashed, but switching to a virtual console and back avoided the reboot, by reinitializing the GPU, but I have also seen crashes when not even the keyboard worked, which should never happen, so a reboot was the only solution. 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. > Microservices need to know who to call how Here there is no difference between a monolithic kernel and a microkernel. With a monolithic kernel, the applications need to know which syscalls to use. Libraries like libc or liburing can be implemented either by using syscalls to a monolithic kernel or messages to the processes that own peripheral devices, without any change in the API used by application programs. Obtaining memory pages shared with device driver processes can be done by creating file mappings for some pseudo-files with standard names, which has no essential difference from doing I/O by opening device nodes from the /dev pseudo-filesystem in UNIX-like OSes. 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. A micro-kernel with the associated device driver processes would contain more or less the same code that is now included in the Linux kernel or in any other monolithic kernel but it would be separated in multiple parts with clear boundaries and interfaces between them. This can only make much easier the reasoning about how the entire system works. The downside is that the interfaces must be well defined. The history of Linux shows a huge number of badly defined interfaces, which later had to be changed. Even in the syscalls, which are supposed to be stable, there are many syscalls already at their fourth or fifth variant, with the previous variants still kept around despite being obsolete, for backwards compatibility with legacy programs. Nevertheless, defining good interfaces is not that difficult, especially today when there is much less pressure to save every bit in a parameter list (even when taking into account the current memory prices). Most Linux interfaces that had to be replaced were replaced for not having features that were obvious as necessary since the beginning, e.g. for not having a parameter with option-encoding flags or for using some data types that were too small. |
| |
| ▲ | frognumber 19 hours ago | parent | next [-] | | > 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. 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. | | |
| ▲ | mike_hearn 18 hours ago | parent [-] | | I think Windows is capable of resetting the GPU and its driver without a hard reboot, actually. At least in theory. | | |
| ▲ | frognumber 7 hours ago | parent [-] | | In theory is right. I've never seen a modern NVidia or AMD reset out of a failed state without a hardware reset. 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. |
|
| |
| ▲ | theamk 2 days ago | parent | prev | next [-] | | Funnily enough, "GPU" (video driver) on Linux used to be microkernel-like: the Xorg would run in userspace and talk to device directly. It was exactly as you described - if Xorg crashed, you could use keyboard shortcut to reinitialize it. And the major motivators for KMS/DRM, which moved a lot of that functionality into kernel, was performance and stability. | |
| ▲ | vsgherzi a day ago | parent | prev [-] | | The asahi Linux gpu driver has gotten pretty darn close to being very solid. |
|
|
| ▲ | johnbarron 2 days ago | parent | prev [-] |
| Same story with Erlang and Elixir systems and their NIFs...the law of leaky abstractions... |
