Now that libkrun, libkrunfw and krunvm have landed in openSUSE
Tumbleweed , I think it's a good time to reopen this discussion. I
also had plenty of time to think about it, and my thoughts are now
clearer, so please let me explain again why bundling a custom kernel
with patches is a critical aspect of the libkrun project, and why this
doesn't pose a risk for neither the Fedora Kernel Team, nor Fedora as
I like to define libkrun as "a dynamic library that enables other
programs to easily gain Virtualization-based isolation capabilities,
with the minimum possible footprint". While it does integrate the
functionality of a VMM (Virtual Machine Monitor), in many aspects is
closer to gVisor  than to QEMU , with the difference that gVisor
uses a microkernel built for that specific purpose, while libkrun
relies on a custom Linux kernel bundled in libkrunfw.
It's in the very nature of the project the need to explore building
new bridges that allow the isolated workload running in the VM to
communicate with the Host, in ways that are more appropriate to
fulfill the needs of use cases such as "Lightweight VMs",
"Virtualization-isolated Containers" or "Trusted Execution
Environments (TEEs)". And this, out of necessity, implies extending
both libkrun and the kernel bundled with it.
Now, I do understand why the actual kernel shipped with Fedora, the
one that will be used by booting thousands of machines and will be
running in privileged mode, needs to be held to sky-high standards,
which may also include the restriction to not include additional
patches, unless it's strongly justified. But, I also think that the
kernel bundled in libkrunfw shouldn't be held by such standards.
The kernel bundled in libkrunfw can and only will be used by libkrun
to bring up the Virtualized environment where the isolated workload
will run. It will only be used in a Virtualization-isolated context,
usually by unprivileged users, and in most cases in a
pre-containerized environment. I argue, and this is a hill I'm willing
to die on, that a bug in either the kernel bundled in libkrunfw or in
libkrun itself, can't cause any more damage than any other userspace
application shipped in Fedora. In fact, the risk is usually lower,
given the context described before.
Having librunfw following the same high standards as the main kernel,
we could end up going against our ability to provide new features to
the users in a timely manner and gather a much needed feedback that's
critical to the success of this project. In practice, this inhibits
the possibility of using Fedora as the main upstream distribution for
libkrun and the projects depending on it. And this would be very
unfortunate, given the roots of libkrun
So, for the reasons stated above, I'd would like to reopen this
question to see if together we can find a compromise that would work
for all of us.
I would like to also recommend that this be reconsidered. We would like
to make libkrun a first class citizen as a crun based OCI Runtime. We
see benefits for it in both on Linux (Fedora) platforms as it provides a
easy to use KVM Container, which works easier with the host then Kata.
Secondarily with MAC systems, since it provides a light weight way of
running containers on a MAC.
In my option, having Fedora's name associated with this innovative
technology would be beneficial to Fedora project.