In a move that’s no doubt going to trigger a lot of confusion and nostalgia, Mklinux is back, in a sense. As the announcement makes clear, this is multikernel Linux, not microkernel Linux, which is an experimental OS designed to run the Linux kernel as a user-space server running on top of OS X’s Mach kernel.
Naming overlap niggles aside, this neo-mklinux lets multiple independent Linux kernels run simultaneously on bare metal. There is still a host kernel which handles the carving up of hardware resources to the newly spawned kernels, but unlike with a hypervisor there are no abstraction or translation layers.
In theory this should mean basically perfect isolation between kernels, which is one of the main selling points along with increased performance. Compared to running KVM guests the provided benchmarks show much lower latency, at between parity to two times faster.
A website is provided with instructions to get started, along with architectural details if that’s your thing.
Perfect isolation? They are running in the same address space with no protection.
I thought you used a racist term in the second paragraph…
Linyos Torovoltos, the creator of lunix would be ashamed!
You can just do the same in for example proxmox and several others. No need for this project.
There doesn’t seem to be any meaningful isolation between the kernels, just a promise not to write all over each other’s memory. In other words, this has essentially no security advantage over a single kernel.
I haven’t checked the further links yet. But just reading from the article: Wouldn’t that be handled by the host OS?
So in other words it’s much like the User Mode Linux arrangement, i.e. UML as the kernel build option with implicit support in the host kernel as standard.
The idea has been termed “AMP” (Asymmetric Multi-Processing). I was told to implement Xilinx XAPP1078 once, where a dual core Cortex-A9 Zynq runs two Linux kernels. This application note is 13 years old now. There was no other OS beneath Linux, but IIRC there was a small snippet of code coordinating access to the L2 cache controller.
Look at what they need to mimic a fraction of an exokernel’s power!
Flicking through the git commits, assuming I found the correct one, I guess my larger niggle with this is more around the vibe coding.
I am sceptical the answer to this zero-day problem and needing to fully gaol agents and their associated daemons isn’t in pinning kernels to cores, hypervisors, or even seperate rebuildable hosts any more.
‘Tis a tough problem.
WTF? The whole point of a kernel is to control the hardware, so why would you want multiple kernels? Is this a FOMO thing? (“everyone must have a kernel!!!”).
Are you going to run a separate file system partition for every kernel? (as in who controls file allocation?). The performance justification is just plain stupid…a properly setup hypervisor and guests can perform within 3% of bare-metal performance (and this is true for both ESX and KVM), so it had to be a particularly bad setup to have shown a two-times improvement.
I think it has finally become time that I find myself an old Amiga somewhere, and return to sane compute.
Interesting! Real world use case would be where a server has multiple third party interface cards, each requiring different and possibly incompatible third party drivers, so isolating the drivers while still running on the same hardware and without the overheads of say kvm.
I wonder if @Joanna would find this interesting for QubesOS, or if the isolation is insufficient. Seems the focus is more on performance than security.
Not Joanna anymore. In June he went back to being Jan Rutkowski.
the announcement doesn’t make sense. promising full isolation while simultaneously avoiding overhead by providing zero isolation. doubletalk gobbledygook. oh look! it’s vibe-coded. doubletalk is a vibe, and now vibes can write code.
reality and meaning are so under-appreciated these days.