Why does the kernel reject my self signed module on a secure boot system?

Question

I have a secure boot enabled linux on an Intel NUC. It uses a special distribution (Balena IoT) that doesn't use shim and has only this distribution's keys enrolled (no Microsoft keys). For a test, I wanted to enroll my own MOK to load a self signed module. That's how I prepared the key (on my normal Debian machine):

openssl req -new -x509 -newkey rsa:2048 -subj "/CN=TLA gru MOK/" -keyout MOK.key -out MOK.crt -days 3650 -nodes -sha256
openssl x509 -in MOK.crt -out MOK.cer -outform DER

Since there is no shim, (and it's not provided by the distribution) I can't use mokutil. Instead, I rebooted the NUC into the firmware and enrolled MOK.cer as an additional key. After another reboot, I checked if that worked:

root@692ff14:~# grep gru /proc/keys
393652e5 I------     1 perm 1f010000     0     0 asymmetri TLA gru MOK: 48dab8f63ef41164535c15799cea88cb216f52df: X509.rsa 216f52df []

root@692ff14:~# dmesg | grep "TLA gru MOK"
[    2.851781] integrity: Loaded X.509 cert 'TLA gru MOK: 48dab8f63ef41164535c15799cea88cb216f52df'

As far as I can tell, it worked. So I picked a random module from the NUC, stripped the existing signature with strip -g btrfs.ko and signed it with my key (again, on my Debian machine):

/usr/lib/linux-kbuild-6.1/scripts/sign-file sha256 MOK/MOK.key MOK/MOK.cer btrfs.ko

I transfered that to the NUC, checked that the signature is available and tried to insmod it:

root@692ff14:/tmp# strings btrfs.ko | tail -n 5
TLA gru MOK
>e],
6P({
#G\:q
~Module signature appended~
root@692ff14:/tmp# lsmod | grep btrfs
root@692ff14:/tmp# insmod ./btrfs.ko 
insmod: ERROR: could not insert module ./btrfs.ko: Key was rejected by service

Now that is disappointing. Why doesn't that work? Did I misunderstand the MOK concept?

Any help is very appreciated.

Answer 1

This is a partial answer because I'm still very unclear as to which EFI variables the Linux kernel loads into which keyrings.

However, enrolling a key as the MOK is not the same as enrolling it into the Secure Boot 'db'. They are two separate lists and the kernel only imports keys from one and not the other.

(Though it certainly doesn't rely on Secure Boot keys as the primary source for module verification either way – it has a compiled-in key generated during kernel build time. MOK is only a secondary source.)

But the reason MokManager needs Shim is because MOK is specifically a Shim-related concept – it is not a standard Secure Boot feature; within EFI it is only used by the additional Secure Boot policies that Shim injects.

(And, quite possibly – although I haven't checked – the Linux kernel may also skip importing the MOK if it sees that Shim isn't present, even though it doesn't actually rely on Shim nor EFI in general for its module verification.)

So if you can't use MokManager because you don't have Shim, I believe the answer is to install Shim so that you could use MokManager.