On Mon, Mar 22, 2021 at 4:23 AM Sergio Lopez <slp@xxxxxxxxxx> 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. > The kernel in this case is a part of the libkrunfw package? I don't 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. 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 acceptable. Justin _______________________________________________ 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
