As I understand it, a crude way to specify a micro kernel might be to call it a specialised slice of a monolithic kernel. It’s still a kernel, and it being more/less efficient, have better security etc depends on the code itself rather than something external.
You’ve got a lot of it, yeah. A microkernel tends to try to implement the smallest amount of essential functionality needed. When used in a specialized environment, like embedded controllers (ex. ZMK firmware, which is built on the Zephyr Kernel), microkernels are great and can exhibit great performance and efficiency.
Once one starts trying to build a general-purpose OS with a microkernel, however, things deteriorate very quickly. Things that are essential for general-purpose computing usually do not make it into the scope of the microkernel’s functionality. This means that anytime something as simple as opening a file is required, a lot more communication is needed between processes, increasing the number of times that calls need to cross between the kernel and user context boundary.
Every context change requires one or more operations and the isolation necessary to be secure, means that they microkernel has to act as a messenger any time that a subsystem needs to communicate with another. The total number of system calls grows at an exponential rate, killing performance and increasing the threat surface that an adversary can target (individual components even end up needing greater awareness of security because there are now a lot more potential “weak links” in the data transmission chain).
Worse performance and increased attack surface due to substantial increase in number of system calls required for any given task?
Oh. You were asking how microkernels are better… They’re smaller. I think that’s about it. Great for things like RTOS where the scope of the kernel is much more limited, specialized, and likely needs to live in an MCU’s tiny ROM.
Absolutely. With local and physical access, attacks are very doable. Starting with a security-conscious architecture means that it’s easier to improve over time.
ETA: The main point is that tech and use cases have evolved. This means that architecture of existing components needs to be re-evaluated for whether they are still a good way of accomplishing a task. In the case of X.org/X11, the architecture is more challenging to secure due to fundamental design. Wayland may not have full parity for remote use yet but, currently, security is generally a higher priority, so, its newer architecture that DOES consider security and sandboxing gives a better starting point in that area.
I fully anticipate that Wayland will also be replaced in the future as tech and use evolves further (does it consider AR/XR? Man-Machine-Interfaces that might see adoption? etc.). Like biology, it’s the nature of tech to evolve and, since there isn’t a sign that bad actors will be absent in the future, Wayland’s architecture will likely end up being insufficient to secure against input logging attacks of the future.
By acting as a man-in-the-middle with the ability to read unencrypted message data (absolutely required in order to try to match against known CSAM), this is absolutely providing a backdoor as well as undermining privacy and security. By needing to trust another party, there is now a greater threat surface which is outside of end user control. One compromised account with access to that third-party is all it would take to extract private details from any messages, undetected, whether for sale on there blackmarket or for suppressing political dissidents, that’s exactly where this would go and we know this because state actors have been caught doing it and getting their toolkits leaked to criminals.
This kind of law doesn’t make children or regular people any safer.