Justin, On Tue, Mar 23, 2021 at 10:30 PM Justin Forbes <jmforbes@xxxxxxxxxxx> wrote: > > 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? 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". > 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. Perfect! 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 > acceptable. 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. Best Regards, -- Fabiano Fidêncio _______________________________________________ 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
