On Tue, Mar 23, 2021 at 10:30 PM Justin Forbes <jmforbes(a)linuxtx.org> wrote:
On Mon, Mar 22, 2021 at 4:23 AM Sergio Lopez <slp(a)redhat.com> wrote:
> 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
> a whole.
> 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.
The kernel in this case is a part of the libkrunfw package?
Sergio will correct me if I'm mistaken, but libkrunfw actually *is*
the kernel bundled in a dynamic library. So, yes, the kernel, in this
case, will be shipped as libkrunfw and there's absolutely no way it
will be mistaken as the "Fedora Kernel".
have a problem with this particular use case, it is not a "kernel"
package, and would not be mistaken as the proper kernel in any sort of
a real context.
With this in mind, I guess we can simply go ahead and file the bug for
adding the package to Fedora.
Sergio, I could happily review that. :-)
On a philosophical note, I would like to see some
effort of getting the patches required upstream in some manner, as any
project relying on external patches long term is just asking for a lot
of unnecessary pain. Even with the patches upstreamed though, a
separate build is still required, and I believe this solution is
Justin, I can say, without any doubt, that we're on the same page here.
There's absolutely zero intent to keep patches downstream, which would
only generate us a huge maintenance burden.
However, we may have to, in some cases, at least for some time.