automate running "`sudo mokutil --import /var/lib/dkms/mok.pub`"

[adrelanos]

As of Debian bookworm, the most non-intuitive, difficult for users to figure out setup step that must be applied on Secure Boot enabled systems is the following:

sudo mokutil --import /var/lib/dkms/mok.pub

This is documented in DKMS readme but that is not easily discovered by users.

[scaronni]

If we automate it, and the user does not know what's happening, it will be prompted with the MOK enrollment screen.

If the user cancels the operation, then the automation will try to rerun it again and again. I'm strongly against this.

What we can do, is to add a hint/message to the output if the MOK key has not been enrolled yet. I'll make a prototype as soon as the other merge request are closed.

[scaronni]

Something like this (fake output):

# dkms build -m nvidia/555.58.02 -k 6.9.7-200.fc40.x86_64
Sign command: /lib/modules/6.9.7-200.fc40.x86_64/build/scripts/sign-file
Signing key: /var/lib/dkms/mok.key
Public certificate (MOK): /var/lib/dkms/mok.pub

The public certificate is not imported yet, please run the following command to allow using the built modules with SecureBoot:
mokutil --import /var/lib/dkms/mok.pub

Cleaning build area... done.
Building module(s)....................... done.
Signing module /var/lib/dkms/nvidia/555.58.02/build/kernel-open/nvidia.ko
Signing module /var/lib/dkms/nvidia/555.58.02/build/kernel-open/nvidia-modeset.ko
Signing module /var/lib/dkms/nvidia/555.58.02/build/kernel-open/nvidia-drm.ko
Signing module /var/lib/dkms/nvidia/555.58.02/build/kernel-open/nvidia-uvm.ko
Signing module /var/lib/dkms/nvidia/555.58.02/build/kernel-open/nvidia-peermem.ko
Cleaning build area... done.

[adrelanos]

Anything would be an improvement over the current state.

However, it seems that DKMS already automates this action on 1 Linux distribution, namely Ubuntu. Here is the related source code copied here for convenience:

    if [[ -z "${mok_signing_key}" ]]; then
        # No custom key specified, use the default key created by update-secureboot-policy for Ubuntu
        # Debian's update-secureboot-policy has no --new-key option
        case "$running_distribution" in
            ubuntu* )
                mok_signing_key="/var/lib/shim-signed/mok/MOK.priv"
                mok_certificate="/var/lib/shim-signed/mok/MOK.der"

                if [[ ! -f ${mok_signing_key} || ! -f ${mok_certificate} ]]; then
                    if [[ ! -x "$(command -v update-secureboot-policy)" ]]; then
                        echo "Binary update-secureboot-policy not found, modules won't be signed"
                        return
                    fi
                    # update-secureboot-policy won't create new key if $mok_certificate exists
                    if [[ -f ${mok_certificate} ]]; then
                        rm -f "${mok_certificate}"
                    fi
                    echo "Certificate or key are missing, generating them using update-secureboot-policy..."
                    SHIM_NOTRIGGER=y update-secureboot-policy --new-key &>/dev/null
                    update-secureboot-policy --enroll-key
                fi

                ;;
        esac
    fi

As per the source code comment "Debian's update-secureboot-policy has no --new-key option" found in the source code I pasted above, it seems like DKMS developers decided they do not wish to run sudo mokutil --import but instead would like to proxy it through update-secureboot-policy. (For me, no having Ubuntu installed.) It's hard to find the source code for update-secureboot-policy and it apparently also does not have a man page. So I don't know yet what it does.

It may provide some sort of "moderation" (avoidance of adding keys the user does not wish to add, avoidance of adding keys over and over again) or other usability features.

Debian as DKMS source code says lacks the --new-key option. I plan to inform Debian in form of a bug report / feature request. Other distributions might totally lack the update-secureboot-policy tool.

[adrelanos]

Ubuntu's update-secureboot-policy source code is here:
https://git.launchpad.net/~ubuntu-core-dev/shim/+git/shim-signed/tree/update-secureboot-policy

Debian's update-secureboot-policy source code is here:
https://salsa.debian.org/efi-team/shim-signed/-/blob/master/update-secureboot-policy?ref_type=heads

[adrelanos]

Debian feature requests:

• dkms: enroll DKMS signing key / automate running “sudo mokutil --import /var/lib/dkms/mok.pub”
• shim-signed: please update update-secureboot-policy / add ‘–new-key’ option

[evelikov]

Fwiw personally I'm not excited about having more distro specific paths. The fact that update-secureboot-policy has diverged across distros (is undocumented, projects lacks CI, contribution guildlines etc) makes things even less compelling.

If the latter is resolved, I would be more supportive of the idea.

[scaronni]

Addign to this that DKMS also supports OpenSSL pkcs11 modules, so you could have the key on an HSM. I think Ubuntu's packaging does not consider this option with update-secureboot-policy.

[norman-a]

Hey guys to piggy back on this thread, if we have a driver to be used across multiple machines, does the dkms generated keys have to be individually enrolled via mokutil in every machine every time there's a kernel or driver upgrade, or is there a better way to automate the enrollment of signed keys on a secure boot UEFI setup?

[scaronni]

If you have some sort of configuration/fleet management (ex. Ansible) you can prepopulate each system with your own keys and preimport them at the first reboot when installing them.

I do this for my systems. The system is PXE booted, installed, same set keys are placed on the filesystem and mokutil is run. First reboot ever they are manually enrolled (you're still in front of the system). From them on, it's just normal updates.