On Thu, Nov 12, 2020 at 01:18:21PM -0600, Justin Forbes wrote: > On Thu, Nov 12, 2020 at 2:38 AM Sergio Lopez <slp@xxxxxxxxxx> wrote: > > > > (This message was originally sent to the Packaging mailing list, where > > Jason Tibbitts pointed that this is a restriction requested by the > > Kernel team, and it'll be your opinion the one that will prevail here) > > > > Hi, > > > > The document "What can be packaged" from "Fedora Packaging > > Guidelines", in the section "Only one kernel package" [1], states that > > "Fedora allows only a single kernel package; packages containing > > alternate kernels are not allowed in the distribution." > > > > While not explicitly stated there, I suspect (please correct me if I'm > > wrong) that statement was written with the idea of preventing > > alternate kernels that could be used to boot the system. With this > > premise in mind, I was wondering if non-bootable kernels (that is, > > kernels in a binary format that's not accepted by a conventional boot > > loader) would be accepted for packaging. > > > > I'm asking this because I would like to package "libkrunfw" [2], a > > dynamic library that bundles an slightly modified minimalist Linux > > kernel. The library doesn't really link against the kernel (in the > > sense that it doesn't resolve any symbols nor calls to any of its > > code), it just bundles it in a binary format that allows it to be > > directly injected in a KVM memory region, so it's quite similar to a > > compressed image format, but for a different use case. > > > > "libkrunfw" is consumed by "libkrun" [3], another dynamic library that > > allows programs to acquire virtualization-based process isolation > > capabilites. The main user of "libkrun" is "crun", when built with > > "--with-libkrun", an OCI runtime used by "podman". When all pieces are > > in place, users can easily run containers with virtualization-based > > isolation by adding some additional flags to the "podman" command > > line. I have a COPR repository with pre-built alternative packages as > > a demonstration [4]. > > > > There are a number of reasons why we can't use the kernel that ships > > with Fedora: > > > > - We carry a small number of patches with minor changes that modify > > the behavior of the kernel for this particular use case. Without > > them, we can't provide an streamlined UX for running isolated > > processes. > > Are these patches not headed upstream? How are these handled with > regards to security updates for the kernel itself, how current do > these patches run? The Fedora kernel tends to be updated once to twice > a week for released versions of Fedora, and we typically have a number > of CVEs flowing in. With this smaller kernel, some of those will not > be relevant, but someone would need to keep up with them, determine if > they are or are not, and apply them if so. Of course it might just be > easier to just always build. The intention is to keep the gap as small as possible by trying to upstream all changes. Probably there will be a some of them that won't make upstream, but those will be super-small changes (such as not complaining loudly if init gets killed) that only make sense for this particular use case. The patches are based on 5.8, but will be rebased on 5.10 as soon its final version is released. > > - We need an aggressive minimalist configuration to reduce the memory > > footprint of each container/isolated process. > > There could be other ways to accomplish this. Our intention is too keep the memory footprint under 50 MiB in total. That's accounting for the weight of the not shared regions of the dynamic libraries, the r/w sections of the kernel, and the memory used by the kernel inside the VM. To achieve that, we rely on very aggressive optimizations such as disabling modularity, enabling options for embedded systems, reducing the maximum number of cores and memory, disabling most options and drivers, optimizing for size (-Os)... > > - We need it to be bundled in a dynamic library, so their contents > > are mapped into the process memory, enabling programs to switch > > between namespaces without the need to carry the kernel binary with > > them. The binary object also needs to be properly aligned to allow > > direct injection into the KVM memory region without additional > > copies. > > > > Given that "libkrunfw" bundles a kernel image that can't be used for > > booting the system, would it be acceptable to package it in Fedora? > > > > It does alleviate some of the concerns, there wouldn't be bugs filed > against the kernel package where we have to figure out what kernel is > being booted, etc. I am still very much concerned about how > updates/security are handled in such a scenario though. I think security shouldn't be a concern here. This may sound silly, but there's a good explanation for it. This kernel will be used by libkrun (which integrates Virtual Machine Monitor functionality) to operate small Virtual Machines where processes that would normally run directly on the host, would run isolated within the VM. The VMM will operate in the same security context as the original process. That is, if the process is the entry point of a container created by podman, the VMM will run in the same namespaces and security profile that the original containerized process would have run. In this scenario, from the host's perspective, even if the guest's kernel suffers some kind of vulnerability, it would still be more secure than running the container without the VM, as the attack surface is smaller (it's the VMM instead arbitrary binaries inside a container), it'll have a more precise seccomp profile (we know the syscalls used by the VMM) and it's still running in the container's security context. In other words, a CVE in the kernel bundled in libkrunfw won't have any impact on the host's security. Thanks, Sergio.
_______________________________________________ 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
