Don't panic It's only 60 Linux CVE security bulletins a week(zdnet.com)
zdnet.com
Don't panic It's only 60 Linux CVE security bulletins a week
https://www.zdnet.com/article/dont-panic-its-only-60-linux-cve-security-bulletins-a-week/
17 comments
We don't panic because we already know that huge monolithic kernels with millions of undetected bugs in ring 0 are still much better than secure micro kernels with 0 bugs in ring 0. Linus made that clear, because Linus
We don't panic because we know that CVE is a somewhat worthless metric.
And yes, the world is stupid for using monolithic kernels. All the people are stupids except me ! (Irony besides: such kernels are used because performance matters in the real world).
And yes, the world is stupid for using monolithic kernels. All the people are stupids except me ! (Irony besides: such kernels are used because performance matters in the real world).
> Irony besides: such kernels are used because performance matters in the real world
Is there that much of a performance penalty anymore? iOS on the latest Apple Silicon still has a massive leap over the benchmarks of the latest Android devices.
Is there that much of a performance penalty anymore? iOS on the latest Apple Silicon still has a massive leap over the benchmarks of the latest Android devices.
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
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
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.
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.
>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.
Alas, Crowdstrike Falcon.
Alas, Crowdstrike Falcon.
Android and Windows are not really fast OSs.
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.
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.
Spot on, and then we have what I call Tanenbaum's revenge, Minix powering Linux kernel on Intel CPUs, and even more clearly, the Linux kernel being used as a plain type 2 hypervisor to run piles of containers for everything.
Regarding Microsoft, they tried a couple of times already, but IBM PC clones culture kind of kills most attempts. Latest one was UWP, with Windows S, Windows WinRT, Windows 10X all supposed to be this kind of approach.
Windows 11 initially was based the tech they could savage from Windows 10X, after it being cancelled.
If anything Crowdstrike has given them a powerful argument to tell OEMs, now the time is come.
Regarding Microsoft, they tried a couple of times already, but IBM PC clones culture kind of kills most attempts. Latest one was UWP, with Windows S, Windows WinRT, Windows 10X all supposed to be this kind of approach.
Windows 11 initially was based the tech they could savage from Windows 10X, after it being cancelled.
If anything Crowdstrike has given them a powerful argument to tell OEMs, now the time is come.
Windows 10X potentially would of prevented the Crowdstrike issue, but some exec at Microsoft clearly didn't like it for whatever reason.
> 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
I feel like those who have the overall decision on the direction of Windows, do not use it, because the OS is filled with many own goals that make it worse compared to macOS (e.g. ads, no atomic updates, constant app changes)
> Windows tacitly enabling the Crowdstrike debacle by underdesigning known vectors of failure is not a blameless situation
The issue could of easily happened on Linux too (in-fact a similar issue did).
I feel like those who have the overall decision on the direction of Windows, do not use it, because the OS is filled with many own goals that make it worse compared to macOS (e.g. ads, no atomic updates, constant app changes)
> Windows tacitly enabling the Crowdstrike debacle by underdesigning known vectors of failure is not a blameless situation
The issue could of easily happened on Linux too (in-fact a similar issue did).
Linux did implement an API for safely instrumenting these types of events, eBPF.
Many EDR and other security products are beginning to use it, although IIRC Crowdstrike does not yet.
Many EDR and other security products are beginning to use it, although IIRC Crowdstrike does not yet.
From 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.
> All Intel chipsets post-2015 are running MINIX 3 internally as the software component of the Intel Management Engine.
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".
So maybe the statement should be "nobody uses microkernels in situations where people might actually care about performance".
> 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)?
Huh? What about QNX, Integrity and L4 (SeL4/OKL4)?
This is what would be called "edge cases" (same for the kernel used for intel ME).
We don't panic becouse we usually don't run hostile code on our computers and on a time share system the other users usually don't try to hack you.