Enable CONFIG_INTEGRITY_CA_MACHINE_KEYRING for DKMS module signing under Secure Boot + lockdown

[doublegate]

Pre-flight checklist

• I have searched existing issues/PRs and this has not been requested before.
• I have read the Contributing Guidelines.

Request type

• New patch / patchset inclusion
• Kernel config change (enable/disable option)
• New kernel variant
• Scheduler tuning / addition
• Compiler / LTO / PGO optimization
• Security hardening
• Driver or hardware enablement
• Other

Summary

Enable CONFIG_INTEGRITY_CA_MACHINE_KEYRING=y in the CachyOS kernel config (mainline and LTS variants).

This option allows CA certificates enrolled via UEFI Secure Boot db or shim MOK to be loaded into the kernel's machine keyring, making them trusted for kernel module signature verification. Without it, enrolled certificates land only in the platform keyring, which is used solely for kernel image (EFI binary) verification and is not consulted during module loading.

Motivation / use case

On CachyOS with Secure Boot enabled and lockdown=integrity active, DKMS-built kernel modules (e.g., VMware Workstation vmmon/vmnet, NVIDIA out-of-tree drivers, openrazer, etc.) cannot be loaded even after correctly signing them with a key enrolled via sbctl or shim MOK.

The root cause: CONFIG_INTEGRITY_CA_MACHINE_KEYRING is not set, so no CA certificates from UEFI db or MokListRT are placed in the machine keyring. The machine keyring is initialized at boot but remains empty, causing all DKMS module signatures to be treated as unverified, which lockdown=integrity then blocks with "unsigned module loading is restricted."

This affects any user running:

• Secure Boot (sbctl or shim/MOK-based enrollment)
• lockdown=integrity (either via cmdline or hardened profile)
• Any out-of-tree DKMS module (VMware, VirtualBox, openrazer, custom drivers, etc.)

The only current workaround is to remove lockdown=integrity from the kernel cmdline, which weakens the kernel hardening posture that CachyOS users reasonably expect to keep alongside Secure Boot.

Fedora and Ubuntu ship with this option enabled as standard. It is part of their recommended Secure Boot + DKMS module signing workflow.

Patch / upstream reference (if available)

Kernel config option: CONFIG_INTEGRITY_CA_MACHINE_KEYRING
Introduced: Linux 5.17 (commit 2a2a1d988b7f "integrity: add a reference to platform keyring in the machine keyring")
Kconfig location: security/integrity/Kconfig
Depends on: CONFIG_INTEGRITY_MACHINE_KEYRING=y (already set in CachyOS)

Fedora kernel config reference:
https://src.fedoraproject.org/rpms/kernel/blob/main/f/kernel-x86_64-fedora.config
(search: CONFIG_INTEGRITY_CA_MACHINE_KEYRING=y)

No patch required — single config line addition.

Testing / benchmarks

Tested on CachyOS (x86_64_v3), kernel 6.19.5-3-cachyos and 6.18.15-3-cachyos-lts:

1. sbctl enrolled a CA-flagged certificate (basicConstraints=critical,CA:TRUE) into UEFI Secure Boot db
2. shim 15.8 installed with MOK enrollment of a dedicated module signing key (CN=VMware Module Signing MOK)
3. vmmon.ko.zst and vmnet.ko.zst signed with sha512 using the enrolled MOK key
4. After boot: sudo keyctl show %:.machine confirms machine keyring is empty
5. journalctl -b -k | grep -i moklist — no MOKLIST entries loaded
6. modprobe fails: "Lockdown: modprobe: unsigned module loading is restricted"

Expected behavior with CONFIG_INTEGRITY_CA_MACHINE_KEYRING=y: CA certs from UEFI db / MokListRT are placed in the machine keyring at boot, module signatures verified against them, DKMS modules load successfully under lockdown=integrity.

Additional context

CONFIG_INTEGRITY_MACHINE_KEYRING is already enabled in CachyOS kernels — the machine keyring infrastructure is there, just not populated from enrolled CA certs. Enabling CONFIG_INTEGRITY_CA_MACHINE_KEYRING is the minimal change to make the full Secure Boot → MOK enrollment → DKMS signing workflow function as expected.

No known conflicts with existing CachyOS patches. Pure config addition.

[1Naim]

The root cause: CONFIG_INTEGRITY_CA_MACHINE_KEYRING is not set, so no CA certificates from UEFI db or MokListRT are placed in the machine keyring. The machine keyring is initialized at boot but remains empty, causing all DKMS module signatures to be treated as unverified, which lockdown=integrity then blocks with "unsigned module loading is restricted."

I don't think that config does what you think it does. The default setting with the config not set is all MOK are added to the machine keyring. If its enabled, only CA keys are added.

6. modprobe fails: "Lockdown: modprobe: unsigned module loading is restricted"

Pretty sure "sign" here means the signature used to sign the module, and not secure boot keys. The kernel generates an ephemeral key during building to sign modules.

DKMS itself generates a MOK for signing the modules, do you have that key enrolled in your system's firmware?

[doublegate]

Thanks for the response, @1Naim. You're right about the config option semantics — I had it backwards. Looking at the kernel source (keyring_handler.c), CONFIG_INTEGRITY_CA_MACHINE_KEYRING is more restrictive, not the enabler: without it, get_handler_for_mok() routes all X.509 MOK certs to add_to_machine_keyring; with it enabled, only CA-flagged certs take that path (leaf certs fall back to .platform).

But I want to share what I found digging deeper, because the actual root cause is different from both of our initial analyses.

---

Root cause: MokListTrustedRT is required

add_to_machine_keyring is only called if imputed_trust_enabled() returns true. From security/integrity/platform_certs/machine_keyring.c:

bool __init imputed_trust_enabled(void) {
    if (efi_enabled(EFI_BOOT))
        return trust_moklist();  // checks for MokListTrustedRT EFI variable
    return true;
}

On UEFI systems, the machine keyring is only populated from MokListRT if the MokListTrustedRT EFI variable exists. This variable is not created by mokutil --import + standard MOK Manager enrollment — it requires a separate mokutil --trust-mok-list command followed by another reboot and MOK Manager confirmation.

This is why keyctl show %:.machine showed empty: MokListTrustedRT was absent, so trust_moklist() returned false, and all MOK certs were routed to .platform regardless of CONFIG_INTEGRITY_MACHINE_KEYRING=y.

To verify:

ls /sys/firmware/efi/efivars/MokListTrustedRT-605dab50-e046-4300-abb6-3dd810dd8b23

If that path doesn't exist, that's the problem.

The fix:

# Step 1: Mark enrolled MOK keys as trusted for the machine keyring
mokutil --trust-mok-list

# Step 2: Reboot, confirm in MOK Manager, reboot again

# Step 3: Verify machine keyring is now populated
sudo keyctl show %:.machine

---

Second issue: sbctl UEFI db keys don't reach .machine

The CA cert I enrolled via sbctl (which goes into the UEFI db) is loaded by load_uefi_certs() into .platform only. There is no code path that bridges UEFI db certs into .machine. So for module signing to work under lockdown=integrity, the signing CA must be enrolled via MOK (mokutil --import), not via sbctl into the UEFI db. Both enrollment paths are needed for different purposes:

Enrollment path	Destination keyring	Used for
sbctl → UEFI db	.platform	EFI binary (kernel/bootloader) verification
mokutil --import → MokListRT	.machine (if MokListTrustedRT set)	Kernel module signature verification

---

On the original config request

I'm withdrawing the root cause analysis from the issue — CONFIG_INTEGRITY_CA_MACHINE_KEYRING does not fix the empty machine keyring problem and is orthogonal to it. The machine keyring is empty because MokListTrustedRT is absent, not because of any missing config option.

That said, I still think the config has independent merit as a security hardening measure: it prevents leaf signing keys from being used as trust anchors in .machine (only CA certs may reside there), which is part of why Fedora ships it alongside their DKMS signing workflow. But that's a separate conversation from fixing the empty keyring.

[1Naim]

Yeah, no. Sorry but I'm not dealing with this slop.