A very exciting set of kernel patches have just been proposed for the Linux kernel, adding multikernel support to Linux.
This patch series introduces multikernel architecture support, enabling multiple independent kernel instances to coexist and communicate on a single physical machine. Each kernel instance can run on dedicated CPU cores while sharing the underlying hardware resources.
↫ Cong Wang on the LKML
The idea is that you can run multiple instances of the Linux kernel on different CPU cores using kexec, with a dedicated IPI framework taking care of communication between these kernels. The benefits for fault isolation and security is obvious, and it supposedly uses less resources than running virtual machines through kvm and similar technologies.
The main feature I’m interested in is that this would potentially allow for “kernel handover”, in which the system goes from using one kernel to the other. I wonder if this would make it possible to implement a system similar to what Android currently uses for updates, where new versions are installed alongside the one you’re running right now, with the system switching over to the new version upon reboot. If you could do something similar with this technology without even having to reboot, that would be quite amazing and a massive improvement to the update experience.
It’s obviously just a proposal for now, and there will be much, much discussion to follow I’m sure, but the possibilities are definitely exciting.
We already have the “switch to new version upon reboot” with fedora atomic/ublue, it can even use systemd-softreboot to switch roots without rebooting the underlying kernel
There are questions about “safety” the current, often times, limited, methods that exist. We’ll see where this all goes.
With the Fedora Atomic method its a fully safe and reliable updating method. You download the update delta and it builds the image on your machine, if its interrupted by an unexpected power off or other event then the image isnt finalised and you cant boot into it. It also keeps one previous image around so you always have a working image, though you can pin more should you need.
Shugo,
Atomic updates are useful, although being atomic doesn’t imply the updates are “safe”. Any time you’ve built code, it’s useful to have automated regression tests for new builds before switching to them, possibly using VMs. Though it’s hard to test things like drivers without physical hardware.
Switching root (using pivot_root syscall) is normally done at boot time, such as after running initrd. This can be done later on a running system, though my preference would be for the OS to swap out it’s own mount point rather than the root fs. Of course this would require the OS to keep it’s resources inside of it’s own mountpoint instead of root. To me this seems like a good idea anyway, better for organization, but it’s not conventional practice for linux distros, which tend to dump things across the file system.
@vinnde
What you are talking about is switching out user environments that are running on top of a single “underlying kernel” as you say. In your example, there is no way to upgrade the “underlying kernel” without a reboot. What is being discussed here is having multiple kernels running in parallel that are all running directly on the “real” hardware. This means you can shutdown and restart an individual Linux kernel while leaving one or more other Linux kernels running the while you do so.
Think of it like a cluster of machines but all on one physical machine with a different Linux kernel per CPU core. If one kernel locks up or crashes, it does not bring “the hardware” offline as the other kernels remain available. The problematic kernel can be restarted. Perhaps running applications can be migrated off the problematic kernel before doing so. Either way, a 50 CPU machine continues to deliver 98% of its CPU capability while rebooting. If the new kernel does not boot, it can be reattempted or rolled-back. It only impacts a single core. But you can roll through all 50, one at a time, to update everything without ever taking the system offline.
There are also security vulnerabilities that involve attacking the CPU to make it leak information about other applications running on the same CPU. With this architecture, you could isolate critical applications to their own CPU core without wasting hardware resources. Even at less extreme isolation, you can have the security of independent Linux kernels without sacrificing native performance or introducing additional attack surface.
Finally, all of these technologies can be used wherever they make the most sense. You can have a Multi Kernel Architecture system that still runs Usermode Linux. You can still run Docker or Podman on it. And you can still host virtual machines. Use what makes the most sense for what you are trying to accomplish.
In essence we get some linux kernel dedicated hypervisor which can run separate kernels. While I’m sure it will save some overhead over more general hypervisor, I’m not sure if it will be more robust and easy to work with.
Being able to partition a baremetal server would be interesting from a hosting perspective. It would be more flexible for people renting dedis to buy a single spec system then carve up the hardware rather then buying different types of servers to rent.
The patchset doesn’t include a hypervisor, though, just an array of all kexec-ed kernels and a simple IPC. I guess guest kernels have to somehow coordinate on its own now. Lots of hype, not much substance.
Is this something like AIX LPARs or I am completely off herE?
It’s sort of like that. Except with commodity hardware, which would be nice.
It’s my understanding there was a service processor which monitored all of that. I think there were some Sun systems which could partition the hardware to run multiple Solaris instances.
@Shuinbird
I do not want to link to it here but look-up “parker linux”. It is a very similar approach to what is being discussed here but even more like LPARs I think.