feat: Add and publish kernel-devel package

[jnohlgard]

This recipe is based on the Fedora kernel-devel RPM build spec 1.

The purpose of this image is to have a published smaller image to use as
a prerequisite when building external modules for the corresponding
kernel.

As a comparison, the size of this kernel-devel image for amd64 is 96 MiB
vs 12.8 GiB for the complete kernel-build intermediate image with all of
the sources and object files.

[smira]

this is something we won't accept, as it would publish an ephemeral signing key which is not what should happen

[jnohlgard]

I don't understand, there are no key files in this image AFAIK?
Is there anything that I can modify in this recipe to make it suitable for publishing?

The important feature here is to get the Module.symvers along with any generated headers and Makefiles in order to be able to build external modules as extensions to the Talos upstream kernel without having to compile the same kernel on my local machine and throwing away the results.

The whole kernel along with the external modules need to be signed by a key that is on the local build machine, but it does not need to recompile everything in order to do that.

[smira]

The build stage generates an ephemeral signing key, so I would stay away from publishing any output of it without huge risk.

Not sure how you see using this output without having the key matching the kernel. So too many questions without answers.

[dsseng]

Basically there's probably a bit of misunderstanding: we don't build external modules outside of pkgs. Take a look at e.g. NVIDIA drivers, they require kernel-build for exactly this reason: they are signed by a key only available there. And the security mechanism currently in use implies kernel and third-party modules are built in the same CI job, and so all those are built in pkgs, not in extensions.

Is the goal to publish a package which will enable users to build modules for the Talos kernel? That's not possible, because kernel module signing is in place for this reason, to avoid unauthorized modules being loaded, so the package with keys mustn't be published to protect system integrity. Publishing only headers, configs etc won't enable making loadable modules, because keys are ephemeral.

However, if you describe the final goal, which modules do you want, we might consider adding them: we can either enable some of the kernel's in-tree modules and those could be later shipped as extensions, or build some third-party modules in the pkgs. At least at this moment all the modules should come from pkgs.

If you need to experiment or do something specific and not suitable for upstream Talos, you could try building Talos yourself, including your pkgs with modules added. There are some other requests for easier builds with custom kernels, so thoughts on this are welcome for us to better understand the desired customization options.

[jnohlgard]

Thanks for the explanations. I will close this PR as not useful in the current state.