5 ms·

i predict that tanenbaum will ultimately win the famous monolithic vs. microkernel design debate. monolithic kernels are good for building features quickly and

by a-dub 5y ago

i predict that tanenbaum will ultimately win the famous monolithic vs. microkernel design debate. 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?

snvzz 5y ago
>what does it matter if your kernel is fast and featureful if you cannot trust it? 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.
- dundarious 5y ago
  You can't really draw conclusions about systems built on Linux vs seL4 from that though. You can have far more IPC in order to do anything useful in microkernels. I'm not dismissing either OS or architecture, but just saying that extrapolating from micro-metrics is very hard when their use in the different architectures varies significantly.
VWWHFSfQ 5y ago
> i predict that tanenbaum will ultimately win the famous monolithic vs. microkernel design debate. 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!
- a-dub 5y ago
  i predict that ultimately the linux kernel will prove too difficult to fully secure. 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.
  - throwaway984393 5y ago
    I think the successor is multikernel. Modern systems trip over themselves to provide isolated runtime environments within one kernel, but it's all a waste once you pop a hole in the one kernel. The answer to that is virtualization of entire kernels, ala Firecracker. 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.
    - deleted 5y ago
      [deleted]
- pjmlp 5y ago
  If he lost why do Linux fakes microkernels with hypervisors and containers to start with? 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.
elihu 5y ago
I think Tanenbaum will win the argument in the sense that the way high-security OS kernels will be written will look like programming a microkernel, but when you look at what the hardware actually executes it'll look like a monolithic kernel. 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.
pjmlp 5y ago
He already won, microkernels are everywhere on the embedded space. 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.

by a-dub 5y ago

snvzz 5y ago

>what does it matter if your kernel is fast and featureful if you cannot trust it? 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.

dundarious 5y ago
You can't really draw conclusions about systems built on Linux vs seL4 from that though. You can have far more IPC in order to do anything useful in microkernels. I'm not dismissing either OS or architecture, but just saying that extrapolating from micro-metrics is very hard when their use in the different architectures varies significantly.

VWWHFSfQ 5y ago

> i predict that tanenbaum will ultimately win the famous monolithic vs. microkernel design debate. 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!

a-dub 5y ago
i predict that ultimately the linux kernel will prove too difficult to fully secure. 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.
- throwaway984393 5y ago
  I think the successor is multikernel. Modern systems trip over themselves to provide isolated runtime environments within one kernel, but it's all a waste once you pop a hole in the one kernel. The answer to that is virtualization of entire kernels, ala Firecracker. 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.
  - deleted 5y ago
    [deleted]
pjmlp 5y ago
If he lost why do Linux fakes microkernels with hypervisors and containers to start with? 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.

elihu 5y ago

I think Tanenbaum will win the argument in the sense that the way high-security OS kernels will be written will look like programming a microkernel, but when you look at what the hardware actually executes it'll look like a monolithic kernel. 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.

pjmlp 5y ago

He already won, microkernels are everywhere on the embedded space. 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.