Meta: Signing of out-of-tree kernel modules

[THS-on]

We (Lernstick) are shipping some out-of-tree modules mainly for better hardware support. We need to do this because we work in a BYOD scenario where we do not own the hardware.

For this reason using DKMS with a machine owner key (MoK) does not really work, because there is often no way for us to enroll a key. Therefore we ship binary packages with signatures that are trusted by our kernel. For each kernel build we generate a temporary key and certificate (secured by a smart card) that is self signed and embedded in the kernel. This key is then used to sign the in- and out-of-tree modules. Additionally we bump the ABI name for each kernel version, similarly to Debian.

There is the problem that some of those modules cannot be distributed fully build and linked because of licensing issues. To work around that, we link those modules at runtime and attach the signatures then. This is similar to the process implemented by NVIDIA and Red Hat for the NVIDIA kernel modules for RHEL (https://github.com/NVIDIA/yum-packaging-precompiled-kmod). Our solution can be found here: https://github.com/Lernstick/dkms-to-deb

Currently there is no public policy on how out-of-tree kernel modules should be handled in the context of Secure Boot. We want to propose the following:

• We start maintaining a list of modules that are shipped by distributions, but are not part of the mainline kernel
  • The list should contain: name, what it does, link to the source code, license and the reason why it is required to work with Secure Boot out-of-the-box.
  • The main goal for now is to track what other modules are out there
  • Extending Meta: Requiring a signing transparency log #291 to also include hashes of those might make sense
• A question about out-of-tree modules and how the keys in the kernel keyring are managed is added to the review
  • Keys should be either manged by an HSM or only used once during build (for in-tree modules)
• Vulnerabilities in kernel modules are treated the same as current kernel vulnerabilities
  • Rebuild of the kernel with new certificate, mark old certificate untrustworthy
  • Revocation of the kernel via SBAT once it is supported (https://github.com/rhboot/shim/blob/main/SBAT.md#kernel-support-for-sbat)

The following out-of-tree kernel modules are currently on our list:

Name	Description	Notes	out-of-the-box requirement	Source
broadcom-sta	Adds support Broadcom wireless chips, that are not supported by the kernel	proprietary: kernel module is linked at startup	hardware support	https://tracker.debian.org/pkg/broadcom-sta
rtl88x2bu	Adds support for Realtek adapters	GPLv2, newer kernel versions have experimental support	hardware support	https://github.com/cilynx/rtl88x2bu
nvidia-graphics-drivers	Driver for NVIDIA graphic cards	proprietary: kernel module is linked at startup, currently version 470 is used	hardware support	https://tracker.debian.org/pkg/nvidia-graphics-drivers
nvidia-graphics-drivers-legacy-390xx	Driver for NVIDIA older graphic cards	proprietary: kernel module is linked at startup, still required for some notebooks with hybrid graphics	hardware support	https://tracker.debian.org/pkg/nvidia-graphics-drivers-legacy-390xx
virtualbox	Kernel drivers required to run VritualBox	CDDL and GPLv3	commonly used application	https://tracker.debian.org/pkg/virtualbox
v4l2loopback	Adds loopback device for V4L2	Used in combination with OBS often in teaching	commonly used application	https://github.com/umlaeute/v4l2loopback

In our understanding none of those modules are providing features to bypass the kernel lockdown, but of course it widens the attack surface of the kernel.

Edit: removed applespi and apple-bce-drv from list (necessary patches are pulled directly as kernel patches), added virtualbox, update signing procedure

[jsetje]

Do you currently have a shim with your own cert in it? Or are you redistributing a third party one?

Generally if you have your own shim, the answer to this should be to sign a certmule that brings in certs for the modules you need:

rhboot/shim#446 (comment)

[THS-on]

Do you currently have a shim with your own cert in it? Or are you redistributing a third party one?

We have a shim with our own cert in it and also build our own kernels.

Generally if you have your own shim, the answer to this should be to sign a certmule that brings in certs for the modules you need

Thank you, this looks like a way enroll the certs. If I understand it correctly, the advantage of using certmule for enrolling the certs instead of embedding them into the kernel keyring is that they are enrolled into MoKList and therefore does not require any changes to the kernel. Does it also have other benefits?