On 3/22/21 05:23, Sergio Lopez wrote:
Hi, Now that libkrun, libkrunfw and krunvm have landed in openSUSE Tumbleweed [1], 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 [2] than to QEMU [3], 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. Thanks, Sergio. [1] https://build.opensuse.org/package/show/openSUSE:Factory/libkrun [2] https://gvisor.dev/ [3] https://www.qemu.org/
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.
_______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
