On Thu, Nov 12, 2020 at 2:38 AM Sergio Lopez <slp(a)redhat.com> 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)
The document "What can be packaged" from "Fedora Packaging
Guidelines", in the section "Only one kernel package" , 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" , 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" , another dynamic library
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
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 .
There are a number of reasons why we can't use the kernel that ships
- 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
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.
- We need an aggressive minimalist configuration to reduce the
footprint of each container/isolated process.
There could be other ways to accomplish this.
- 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
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.