Is acceptable to package non-bootable kernels?

[Sergio Lopez]

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 packaging non-bootable kernels
(that is, kernels is 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.

 - We need an aggressive minimalist configuration to reduce the memory
   footprint of each container/isolated process.

 - 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?

Thanks,
Sergio.

[1]
https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-pac...
[2] https://github.com/containers/libkrunfw
[3] https://github.com/containers/libkrun
[4] https://copr.fedorainfracloud.org/coprs/slp/crun-krun/

[Jason Tibbitts]

> >>>> Sergio Lopez <slp(a)redhat.com&gt; writes: 
>  I was wondering if packaging non-bootable kernels (that is, kernels
> is
>  a binary format that's not accepted by a conventional boot loader)
>  would be accepted for packaging. 
I would say the answer is basically "ask the kernel folks".  The
restrictions on packaging kernels were added to make the lives of the
kernel folks easier (and at their request, many years ago).  If they
have no problem with packaging these kernels then the packaging
committee won't have any problem with it, either.

 - J<

[Sergio Lopez]

On Wed, Nov 11, 2020 at 10:05:33AM -0600, Jason Tibbitts wrote:
>  >>>>> Sergio Lopez <slp(a)redhat.com&gt; writes:
>  
>  > I was wondering if packaging non-bootable kernels (that is, kernels is
>  > a binary format that's not accepted by a conventional boot loader)
>  > would be accepted for packaging.
>  
>  I would say the answer is basically "ask the kernel folks".  The
>  restrictions on packaging kernels were added to make the lives of the
>  kernel folks easier (and at their request, many years ago).  If they
>  have no problem with packaging these kernels then the packaging
>  committee won't have any problem with it, either.
>   
OK, I'll ask them. Thanks, Jason.

BR,
Sergio.