As an example, think of how Rust treats thread communication. The API looks like you're passing messages, but the whole data isn't being copied when you send a message, you're just sending a pointer. The compiler keeps track of making sure ownership rules are respected.
One of the nice things about using a message passing API internally even if the implementation is just single-address-space shared memory is that if you really want more security you can change the implementation to be one where actual message passing takes place, and threads are isolated into separate address spaces like you would do in a proper microkernel. Whether you turn that on or not depends on whether security or performance are more important for your chosen application. It would be much harder to convert something like the Linux kernel into a microkernel.
Tanenbaum already lost the debate a long time ago. Minix is running in Intel CPUs but it's hardly exercising the benefits of a micro-kernel architecture. General-purpose PCs are running mono-kernels.
Maybe the micro-kernel will prove useful at some point in the future, but that's just theoretical. But _this_ war was lost. Maybe they'll win the next one!
i predict that the successor will ultimately be a microkernel architecture with ipc that is built from the ground up to be hardened against hostile components and will be accelerated in hardware. i predict we'll see something like realtime cryptographic proofs of both the identity and correct execution of operating system component code and the code of user programs.
Rather than tying ourselves into knots trying to extend the one kernel, we can just run 50 kernels, and have abstractions to connect them into a distributed OS (think Plan9). This allows the kernel to be simpler, provides an easier path to standardized interfaces between components, and lets us infinitely scale a single system, with stronger isolation guarantees.
It's basically a microkernel but the components are farther apart. And because of that you can do things like have multiple different kernel versions interoperate over one stable abstraction/API/whatever. SSI clusters are another example of this, they just happen to be using the same kernel, but they don't have to.
Also Android has tamed Linux into a pseudo-microkernel with Project Treble, where all drivers are their own processes using Android IPC.
On Android traditional Linux drivers are considered "legacy" and kept around for compatibility with upstream and previous Android versions pre-Treble.
And lets not forget that those running Intel hardware need Minix to run Linux.
Ah and containers are nothing more than playing at microkernels with monolith OSes.
And if the kernel is Linux, I'm not so sure about fast.
Relative to Linux, seL4 has:
- Order of magnitude faster context switch.
- Order of magnitude lower scheduler latency.
- Order of magnitude faster Inter-Process Communication.
monolithic kernels are good for building features quickly and runtime performance, but the security design reminds me of 90s era computer security approaches, where firewalls were supposed to stop all threats and behind them security was lax on internal networks. microkernels are much more similar to today's more effective defense in depth approaches.
what does it matter if your kernel is fast and featureful if you cannot trust it?