5 ms·

Yes there is. The ability to pass just call other subsystems functions, using the same memory is the key. This is why, as far as I know, there are no microkern

Yes there is. The ability to pass just call other subsystems functions, using the same memory is the key. This is why, as far as I know, there are no microkernels on the field (except some edge cases, probably). For years, people has been working to do zero-copy between userspace and hardware, to gain even more performance

gus_massa 2y ago
From https://en.wikipedia.org/wiki/Minix#MINIX_3 https://en.wikipedia.org/wiki/Minix#MINIX_3 > All Intel chipsets post-2015 are running MINIX 3 internally as the software component of the Intel Management Engine.
- AnimalMuppet 2y ago
  If the argument is "nobody uses microkernels because performance", then I'm not sure that Intel Management Engine is really a counterargument. Does performance actually matter for Intel Management Engine? Isn't it pretty low-bandwidth? So maybe the statement should be "nobody uses microkernels in situations where people might actually care about performance".
a-french-anon 2y ago
> This is why, as far as I know, there are no microkernels on the field (except some edge cases, probably). Huh? What about QNX, Integrity and L4 (SeL4/OKL4)?
- JackSlateur 2y ago
  This is what would be called "edge cases" (same for the kernel used for intel ME).
pjmlp 2y ago
Besides the already provided examples on sibling comments, Linux drivers on Android are considered legacy, all modern drivers since Project Treble, execute on their own process and use Android IPC to talk to the kernel. Likewise, while macOS still allows for kexts, the long term roadmap is that only userspace extensions are allowed in future versions, including drivers. Kexts are only still supported as interim solution for the respective companies to migrate their products away from macOS kernel. Finally, Windows nowadays with Secure Kernel, Device Guard, and Virtualization-based Security already cages lots of stuff that shouldn't be freely having fun on ring 0.
- aeadio 2y ago
  A reminder that monolithic- vs micro-kernel is a spectrum. You can achieve the benefits of microkernels incrementally, as both Android and MacOS/iOS are proving out -- by moving components into userspace piecemeal, over time. And you can reap the benefits of microkernel ideas in isolated domains. Apple is choosing to benefit from microkernel style userspace APIs for third party code in particular, because that's a very likely vector for security and stability issues. You simply can't know what degree of testing and safety practices are being employed by third parties, and their crash analytics almost certainly bear out that most system crashes happen there. Microkernels are not an automatic antithesis of performance. As usual, you have to make informed tradeoffs. Do you keep components X in ring 0, or not? And if you move it out, how do you design the interface between the two to try and mitigate the performance impact of that choice. In the case of Apple with MacOS, additionally, how do you develop the SoC in tandem to make the context switch cheaper? (Really, Apple's apparent competitive advantage from vertical integration between hardware and software is a farce. There was never anything stopping Microsoft from approaching Intel and AMD and working jointly on making the same kind of improvements at the hardware level for the benefit of the software. They just didn't care enough to do so.) That the industry gave up on microkernels is not a testament to them being untenable from a performance perspective. It's a testament to the laziness and lack of willpower to advance the state of the art because insecure and unreliable systems were good enough for their customers. The way our technology looks today is not some utopian extension of all the best ideas we've come up with so far. Choices like monolithic kernels coming to dominate is not evidence that they're a more fit solution. It's evidence that defeatism is the path of least resistance. When I see Apple do stuff like move to deprecate kexts, I take it as evidence that they give more of a shit about the quality and robustness of their software than the next guys. Meanwhile, we still have Windows forcing EDR components to operate in ring0 and bring down entire industries when a bug happens because they couldn't be bothered to implement a safe API for EDRs in which a memory safety issue -- which we are all acutely aware happen all the time -- won't crash the kernel. Windows tacitly enabling the Crowdstrike debacle by underdesigning known vectors of failure is not a blameless situation. Crowdstrike has taken more flack than they deserve here, because we've known about issues like this at the platform level, and Microsoft's competitors have even taken the time to fix what Microsoft couldn't be bothered to. Ideas like microkernels are what you get when people analyze the technical deficiencies in the state of the art, and then go and try to come up with solutions. Of course there's challenges. But that pure microkernels on their own are at a performance disadvantage compared to monolithic kernels is not because that line of thinking is a dead end, but because nobody bothered to put in the R&D to solve it.

gus_massa 2y ago

From https://en.wikipedia.org/wiki/Minix#MINIX_3 https://en.wikipedia.org/wiki/Minix#MINIX_3 > All Intel chipsets post-2015 are running MINIX 3 internally as the software component of the Intel Management Engine.

AnimalMuppet 2y ago
If the argument is "nobody uses microkernels because performance", then I'm not sure that Intel Management Engine is really a counterargument. Does performance actually matter for Intel Management Engine? Isn't it pretty low-bandwidth? So maybe the statement should be "nobody uses microkernels in situations where people might actually care about performance".

a-french-anon 2y ago

> This is why, as far as I know, there are no microkernels on the field (except some edge cases, probably). Huh? What about QNX, Integrity and L4 (SeL4/OKL4)?

JackSlateur 2y ago
This is what would be called "edge cases" (same for the kernel used for intel ME).

pjmlp 2y ago

Besides the already provided examples on sibling comments, Linux drivers on Android are considered legacy, all modern drivers since Project Treble, execute on their own process and use Android IPC to talk to the kernel. Likewise, while macOS still allows for kexts, the long term roadmap is that only userspace extensions are allowed in future versions, including drivers. Kexts are only still supported as interim solution for the respective companies to migrate their products away from macOS kernel. Finally, Windows nowadays with Secure Kernel, Device Guard, and Virtualization-based Security already cages lots of stuff that shouldn't be freely having fun on ring 0.

aeadio 2y ago
A reminder that monolithic- vs micro-kernel is a spectrum. You can achieve the benefits of microkernels incrementally, as both Android and MacOS/iOS are proving out -- by moving components into userspace piecemeal, over time. And you can reap the benefits of microkernel ideas in isolated domains. Apple is choosing to benefit from microkernel style userspace APIs for third party code in particular, because that's a very likely vector for security and stability issues. You simply can't know what degree of testing and safety practices are being employed by third parties, and their crash analytics almost certainly bear out that most system crashes happen there. Microkernels are not an automatic antithesis of performance. As usual, you have to make informed tradeoffs. Do you keep components X in ring 0, or not? And if you move it out, how do you design the interface between the two to try and mitigate the performance impact of that choice. In the case of Apple with MacOS, additionally, how do you develop the SoC in tandem to make the context switch cheaper? (Really, Apple's apparent competitive advantage from vertical integration between hardware and software is a farce. There was never anything stopping Microsoft from approaching Intel and AMD and working jointly on making the same kind of improvements at the hardware level for the benefit of the software. They just didn't care enough to do so.) That the industry gave up on microkernels is not a testament to them being untenable from a performance perspective. It's a testament to the laziness and lack of willpower to advance the state of the art because insecure and unreliable systems were good enough for their customers. The way our technology looks today is not some utopian extension of all the best ideas we've come up with so far. Choices like monolithic kernels coming to dominate is not evidence that they're a more fit solution. It's evidence that defeatism is the path of least resistance. When I see Apple do stuff like move to deprecate kexts, I take it as evidence that they give more of a shit about the quality and robustness of their software than the next guys. Meanwhile, we still have Windows forcing EDR components to operate in ring0 and bring down entire industries when a bug happens because they couldn't be bothered to implement a safe API for EDRs in which a memory safety issue -- which we are all acutely aware happen all the time -- won't crash the kernel. Windows tacitly enabling the Crowdstrike debacle by underdesigning known vectors of failure is not a blameless situation. Crowdstrike has taken more flack than they deserve here, because we've known about issues like this at the platform level, and Microsoft's competitors have even taken the time to fix what Microsoft couldn't be bothered to. Ideas like microkernels are what you get when people analyze the technical deficiencies in the state of the art, and then go and try to come up with solutions. Of course there's challenges. But that pure microkernels on their own are at a performance disadvantage compared to monolithic kernels is not because that line of thinking is a dead end, but because nobody bothered to put in the R&D to solve it.