3 ms·

Microkernel does seem the only sensible path forward. Even if the kernel is slowly rustified, going to be playing security whack-a-mole for a long time.

anonymousiam 4y ago
Back in the day when the micro-kernel/monolith flamewars were raging, the arguments for monolith were about improved performance and lower memory usage. I haven't seen much discussion on this topic for years, but at least those two arguments have not aged well.
- aflag 4y ago
  Why not? It isn't clear to me why monolithic kernel wouldn't still have better performance.
  - pjmlp 4y ago
    It doesn't matter with layers hypervisors, virtualization, containers and sandboxes running on top. All mitigations to achieve microkernel like capabilities.
    - aflag 4y ago
      Hm, if you're making the underlying hardware slower, don't you want the kernel to be even faster though? VMs are much more than micro kernels. It's about allowing the user to install whatever they want in their machine. Containers are just a userland abstraction. Not sure where the link to microkernels is there.
      - pjmlp 4y ago
        Not when using hypervisor type 1.
        aflag 4y ago
        Why not? Hypervisor type 1 has less overhead, but it's still not quite the same as running directly on the box. I don't think micro kernels would replace those anyway. To be honest, I don't even really see the connection between running most of the kernel in user space and allowing concurrent systems to run in the same hardware.
        snvzz 4y ago
        seL4 with its VMM is a better hypervisor architecture than, say, Xen. Xen is unfortunately large, and the full hypervisor runs privileged. With seL4, VM exceptions are forwarded to VMM, which handles them. From a security standpoint, a VM escape would only yield VMM privileges, which are no higher than that of the VM itself. This is much better than a compromise of Xen, which would compromise all VMs in the system. Makatea[0] is an effort to build a Qubes-like system using seL4 and its virtualization support. It is currently funded by a NLNet grant. 0. https://trustworthy.systems/projects/TS/makatea https://trustworthy.systems/projects/TS/makatea
- pjmlp 4y ago
  Mostly because the cloud is based on microkernel like approach regardless of the kernel. Hypervisors, userspace drivers, containers, language runtime sandboxes, bytecode deployments, driver and kernel sandboxes (safe kernel / driver guard),container only distributions,...
- mananaysiempre 4y ago
  Spectre and friends seem to have killed Liedtke’s fast synchronous IPC, unfortunately. Of course, there’s still asynchronous IPC, exokernels (perhaps the closest thing to today’s containers), and so on.
galangalalgol 4y ago
For rack servers you could probably get away with a number of microkernel os today. Desktop has clear options in that regard, but you are giving up op n source.
CorbetL 4y ago
Linux may eventually become a microkernel with most IPC done via io_uring, but it may take 20 years to reach this state.
- touisteur 4y ago
  Right now it seems microvms are the way. Build an extremely minimal tailored kernel+userland for network-facing components. If you don't have nf_tables built-in (and it's not loadable because not present) this vulnerability isn't a problem. I mean, right now to use it one would have to chain it with a RCE on your userland app (or on the kernel but just skip the nf_tables step then...). Then one would have to escape the VM, then if you're using firecracker or crosvm, you'll have to break seccomp. Still imaginable, but by then I guess the next kernel (or userland app) fix release is already available :-) and you're already rebooting your microvm. If you can CI/CD in minutes a reduced kernel+app and reboot in 100ms your network-facing thing (be it nginx or haproxy) you might just take latest vanilla anyway...
- ttarr 4y ago
  Care to elaborate plz? How would we go about GPUs, NCs, and many kinds of drivers?

anonymousiam 4y ago

Back in the day when the micro-kernel/monolith flamewars were raging, the arguments for monolith were about improved performance and lower memory usage. I haven't seen much discussion on this topic for years, but at least those two arguments have not aged well.

aflag 4y ago
Why not? It isn't clear to me why monolithic kernel wouldn't still have better performance.
- pjmlp 4y ago
  It doesn't matter with layers hypervisors, virtualization, containers and sandboxes running on top. All mitigations to achieve microkernel like capabilities.
  - aflag 4y ago
    Hm, if you're making the underlying hardware slower, don't you want the kernel to be even faster though? VMs are much more than micro kernels. It's about allowing the user to install whatever they want in their machine. Containers are just a userland abstraction. Not sure where the link to microkernels is there.
    - pjmlp 4y ago
      Not when using hypervisor type 1.
      - aflag 4y ago
        Why not? Hypervisor type 1 has less overhead, but it's still not quite the same as running directly on the box. I don't think micro kernels would replace those anyway. To be honest, I don't even really see the connection between running most of the kernel in user space and allowing concurrent systems to run in the same hardware.
        snvzz 4y ago
        seL4 with its VMM is a better hypervisor architecture than, say, Xen. Xen is unfortunately large, and the full hypervisor runs privileged. With seL4, VM exceptions are forwarded to VMM, which handles them. From a security standpoint, a VM escape would only yield VMM privileges, which are no higher than that of the VM itself. This is much better than a compromise of Xen, which would compromise all VMs in the system. Makatea[0] is an effort to build a Qubes-like system using seL4 and its virtualization support. It is currently funded by a NLNet grant. 0. https://trustworthy.systems/projects/TS/makatea https://trustworthy.systems/projects/TS/makatea
pjmlp 4y ago
Mostly because the cloud is based on microkernel like approach regardless of the kernel. Hypervisors, userspace drivers, containers, language runtime sandboxes, bytecode deployments, driver and kernel sandboxes (safe kernel / driver guard),container only distributions,...
mananaysiempre 4y ago
Spectre and friends seem to have killed Liedtke’s fast synchronous IPC, unfortunately. Of course, there’s still asynchronous IPC, exokernels (perhaps the closest thing to today’s containers), and so on.

galangalalgol 4y ago

For rack servers you could probably get away with a number of microkernel os today. Desktop has clear options in that regard, but you are giving up op n source.

CorbetL 4y ago

Linux may eventually become a microkernel with most IPC done via io_uring, but it may take 20 years to reach this state.

touisteur 4y ago
Right now it seems microvms are the way. Build an extremely minimal tailored kernel+userland for network-facing components. If you don't have nf_tables built-in (and it's not loadable because not present) this vulnerability isn't a problem. I mean, right now to use it one would have to chain it with a RCE on your userland app (or on the kernel but just skip the nf_tables step then...). Then one would have to escape the VM, then if you're using firecracker or crosvm, you'll have to break seccomp. Still imaginable, but by then I guess the next kernel (or userland app) fix release is already available :-) and you're already rebooting your microvm. If you can CI/CD in minutes a reduced kernel+app and reboot in 100ms your network-facing thing (be it nginx or haproxy) you might just take latest vanilla anyway...
ttarr 4y ago
Care to elaborate plz? How would we go about GPUs, NCs, and many kinds of drivers?