Kernel: Introduce Multikernel Architecture Support
34 comments
·September 19, 2025tremon
elteto
You just don't share certain devices, like Bluetooth. The "main" kernel will probably own the boot process and manage some devices exclusively. I think the real advantage is running certain applications isolated within a CPU subset, protected/contained behind a dedicated kernel. You don't have the slowdown of VMs, or have to fight against the isolation sieve that is docker.
yjftsjthsd-h
That's fine for
- Enhanced security through kernel-level separation
- Better resource utilization than traditional VM (KVM, Xen etc.)
- Improved fault isolation between different workloads
- Potential zero-down kernel update with KHO (Kernel Hand Over)
raron
> since if the "main" kernel crashes or is supposed to get upgraded then you have to hand hardware back to it.
Isn't that similar to starting up from hibernate to disk? Basically all of your peripherals are powered off and so probably can not keep their state.
Also you can actually stop a disk (member of a RAID device), remove the PCIe-SATA HBA card it is attached to, replace it with a different one, connect all back together without any user-space application noticing it.
vlovich123
Is there anything that says that multiple kernels will be responsible for owning the drivers for HW? It could be that one kernel owns the hardware while the rest speak to the main kernel using a communication channel. That's also presumably why KHO is a thing because you have to hand over when shutting down the kernel responsible for managing the driver.
messe
Reminds me of exokernel architectures[0.5][1.5][2.5]. How is non-CPU resource multiplexing handled, or planned to be handled?
[0.5]: https://en.wikipedia.org/wiki/Exokernel
[1.5]: https://wiki.osdev.org/Exokernel
[2.5]: "Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration." — Stan Kelly-Bootle
ch_123
Reminds me of OpenVMS Galaxy on DEC Alpha systems, which allowed multiple instances of the OS to run side by side on the same hardware without virtualization.
https://www.digiater.nl/openvms/doc/alpha-v8.3/83final/aa_re...
skissane
IBM mainframes and Power servers have “partitions” (LPARs). My understanding of how they work, is they actually are software-based virtualisation, but the hypervisor is in the system firmware, not the OS. And some of the firmware is loaded from disk at boot-up, making it even closer to something like Xen-labelling it as “hardware” not “software” is more about marketing (and which internal teams own it within IBM) than than technical reality. Their mainframe partitioning system, PR/SM, apparently began life as a stripped-down version of VM/CMS, although I’m not sure how close the relationship between PR/SM and z/VM is in current releases.
This sounds like running multiple kernels in a shared security domain, which reduces the performance cost of transitions and sharing, but you lose the reliability and security advantages that a proper VM gives you. It reminds me of coLinux (essentially, a Linux kernel as a Windows NT device driver)
Does anyone have more details on how OpenVMS Galaxy was actually implemented? I believe it was available for both Alpha and Itanium, but not yet x86-64 (and probably never…)
andutu
Pretty cool, sound similar to what Barrelfish OS enabled (https://barrelfish.org/).
zokier
Interestingly the author has a startup revolving around this technology. Their webpage has some info: https://multikernel.io/
sargun
The author (Cong Wang) is building all sorts of neat stuff. Recently, they built kernelscript: https://github.com/multikernel/kernelscript -- another DSL for BPF that's much more powerful than the C alternatives, without the complexity of C BPF. Previously, they were at Bytedance, so there's a lot of hope that they understand the complexities of "production".
rwmj
Sounds similar to CoLinux where you could run a "cooperative Linux" alongside Windows http://www.colinux.org/
joseph2024
HP printers are similar. They run Linux on two cores and an RTOS on the other.
brcmthrowaway
This was underrated!
IAmLiterallyAB
What's preventing a compromised kernel on one core from hijacking the other cores? This doesn't seem like much of a security boundary
viraptor
Nothing prevents it if you achieve code execution. But where it helps is scenarios like syscall / memory mapping exploits where a user process can only affect resources attached to their current kernel. For example https://dirtycow.ninja/ would have a limited scope.
null
yalogin
It’s not clear to me but do these kernels run directly on the hardware? If so how are they able to talk to each other, DMA? That could open up some security flaws, hopefully they thought through that
agentkilo
IIUC, yes, all the kernels involved run directly on the hardware, in a "cooperative" way, i.e. they must agree on not touching others' memory regions.
I think the architecture assumes all loaded kernels are trusted, and imposes no isolation other than having them running on different CPUs.
Given the (relative) simplicity of the PoC, it could be really performant.
yjftsjthsd-h
Can't the kernel set up hardware-backed memory maps to partially blind itself to other memory regions? (Only "partially" because even then I expect it could just change the mappings, but it's still a protection against accidental corruption)
yalogin
Wonder what the use cases are. Doesn’t feel like the kernels are hotswappable, so why is it preferred over VMs?
9cb14c1ec0
It would be interesting to see a detailed security assessment of this. Would it provide security improvements over docker?
eqvinox
Docker is the wrong thing to compare against, especially considering it is an application and not a technology; the technology would be containerization. This competes against hardware virtualization support, if anything.
perching_aix
Does this mean resiliency against kernel panics?
sedatk
> - Improved fault isolation between different workloads
Yes.
ATechGuy
That's what the author is claiming. Practically, VM-level strong fault isolation cannot be achieved without isolation support from the hardware aka virtualization.
eqvinox
Hardware without something like SR-IOV is straight up going to be unshareable for the foreseeable future; things like ring buffers would need a whole bunch of coordination between kernels to share. SR-IOV (or equivalent) makes it workable, an IOMMU (or equivalent) then provides isolation.
loeg
Insane idea, but very cool.
"while sharing the underlying hardware resources"? At the risk of sounding too positive, my guess is that hell will freeze over before that will work reliably. Alternating access between the running kernels is probably the "easy" part (DMA and command queues solve a lot of this for free), but I'm thinking more of all the hardware that relies on state-keeping and serialization in the driver. There's no way that e.g. the average usb or bluetooth vendor has "multiple interleaved command sequences" in their test setup.
I think Linux will have to move to a microkernel architecture before this can work. Once you have separate "processes" for hardware drivers, running two userlands side-by-side should be a piece of cookie (at least compared to the earlier task of converting the rest of the kernel).
Will be interesting to see where this goes. I like the idea, but if I were to go in that direction, I would choose something like a Genode kernel to supervise multiple Linux kernels.