Skip to content

Commit c0901aa

Browse files
committed
docs(secure-boot): add DKMS/MOK kernel module signing section
Document how to get MOK-signed DKMS modules (nvidia, openrazer, etc.) to load under Secure Boot: DKMS signs with /var/lib/dkms/mok.key, and the key must be enrolled as a MOK (via shim, since the sbctl setup has no shim) so the kernel trusts it in the .machine keyring. Requires a CachyOS kernel built with IMA (CONFIG_IMA_SECURE_AND_OR_TRUSTED_BOOT); see CachyOS/linux-cachyos#862 and #863.
1 parent e4843c0 commit c0901aa

1 file changed

Lines changed: 80 additions & 0 deletions

File tree

src/content/docs/configuration/secure_boot_setup.mdx

Lines changed: 80 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -277,6 +277,86 @@ sudo sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/
277277
</TabItem>
278278
</Tabs>
279279

280+
## Signing Kernel Modules (DKMS / MOK)
281+
282+
When Secure Boot is enabled, the kernel refuses to load any module that is not
283+
signed by a key it trusts. Modules shipped with the kernel are already signed
284+
with CachyOS's build key, but out-of-tree modules built locally through
285+
[DKMS](https://wiki.archlinux.org/title/Dynamic_Kernel_Module_Support) — for
286+
example `openrazer` — are signed with a separate key that the kernel does not
287+
trust by default. Until that key is enrolled, these modules fail to load:
288+
289+
```sh
290+
modprobe: ERROR: could not insert 'razerkbd': Operation not permitted
291+
```
292+
293+
DKMS already signs every module it builds with a Machine Owner Key (MOK) stored
294+
at `/var/lib/dkms/mok.key` (private key) and `/var/lib/dkms/mok.pub`
295+
(certificate). What is missing is telling the firmware and kernel to *trust*
296+
that key, which is done by enrolling the certificate as a MOK. Because this
297+
guide sets up Secure Boot with `sbctl` alone, `shim` — which performs the MOK
298+
enrollment — has to be added to the boot chain first.
299+
300+
:::note[Root permissions are required for the following steps.]
301+
:::
302+
303+
<Steps>
304+
305+
1. Install `shim` and `mokutil`:
306+
```sh
307+
sudo pacman -S --needed shim-signed mokutil
308+
```
309+
2. Copy `shim`, `MokManager` and a copy of your boot manager into a directory on
310+
the ESP, then sign them with `sbctl`. `shim` chainloads a file named
311+
`grubx64.efi` next to itself, so the boot manager is copied under that name:
312+
```sh title="Example for systemd-boot with the ESP mounted at /boot:"
313+
sudo mkdir -p /boot/EFI/shim
314+
sudo cp /usr/share/shim-signed/shimx64.efi /boot/EFI/shim/shimx64.efi
315+
sudo cp /usr/share/shim-signed/mmx64.efi /boot/EFI/shim/mmx64.efi
316+
sudo cp /boot/EFI/systemd/systemd-bootx64.efi /boot/EFI/shim/grubx64.efi
317+
sudo sbctl sign /boot/EFI/shim/shimx64.efi
318+
sudo sbctl sign /boot/EFI/shim/mmx64.efi
319+
sudo sbctl sign /boot/EFI/shim/grubx64.efi
320+
```
321+
:::note
322+
Adjust the paths for your setup. The file copied to `grubx64.efi` must be the
323+
EFI binary your system currently boots (e.g. Limine or GRUB instead of
324+
systemd-boot).
325+
:::
326+
3. Add a firmware boot entry that launches `shim`, keeping your existing entry as
327+
a fallback:
328+
```sh title="Replace the disk and partition number with those of your ESP."
329+
sudo efibootmgr -c -d /dev/nvme0n1 -p 1 -L "shim" -l '\EFI\shim\shimx64.efi'
330+
```
331+
4. Queue the DKMS key for enrollment and set a one-time password when prompted:
332+
```sh
333+
sudo mokutil --import /var/lib/dkms/mok.pub
334+
```
335+
5. Reboot. `shim` launches **MokManager** (a blue screen): choose
336+
**Enroll MOK → Continue → Yes**, enter the password from the previous step,
337+
then reboot.
338+
339+
</Steps>
340+
341+
After the reboot, confirm the key was loaded into the `.machine` keyring:
342+
343+
```sh title="The DKMS module signing key should be listed:"
344+
sudo grep -iE '\.machine|dkms' /proc/keys
345+
```
346+
347+
:::note[Empty `.machine` keyring]
348+
If `.machine` is still empty, enable trust for MOK keys in the kernel keyring,
349+
reboot once more and confirm the prompt in MokManager:
350+
351+
```sh
352+
sudo mokutil --trust-mok
353+
```
354+
:::
355+
356+
The previously blocked modules now load on boot. DKMS re-signs its modules
357+
automatically on every rebuild and the MOK stays enrolled across kernel updates,
358+
so this enrollment only needs to be done once.
359+
280360
## Secure Boot Status Check
281361

282362
To check that secure boot is indeed enabled. You can run one of the following commands

0 commit comments

Comments
 (0)