dkms in bullseye has a sign script that expect the mok key to be in /root (not /var/lib/dkms/:
dkms: /etc/dkms/sign_helper.sh /lib/modules/"$1"/build/scripts/sign-file sha512 /root/mok.priv /root/mok.der "$2" dkms in bookworm has no sign_tool script anymore but from https://salsa.debian.org/debian/dkms/-/blob/debian/3.0.8-3/dkms.in via do_build then preapre_signing it sets sign_file: debian* ) sign_file="/usr/lib/linux-kbuild-${kernelver%.*}/scripts/sign-file" and a MOK location (and also generate this MOK if mok_singing_key is not defined in /etc/dkms/framework.conf): 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 [ ! "${mok_signing_key}" ]; then mok_signing_key="/var/lib/dkms/mok.key" fi echo "Signing key: $mok_signing_key" if [ ! "${mok_certificate}" ]; then mok_certificate="/var/lib/dkms/mok.pub" fi echo "Public certificate (MOK): $mok_certificate" # scripts/sign-file.c in kernel source also supports using "pkcs11:..." as private key if [[ "$mok_signing_key" != "pkcs11:"* ]] && ( [ ! -f "$mok_signing_key" ] || [ ! -f "$mok_certificate" ] ); then echo "Certificate or key are missing, generating self signed certificate for MOK..." openssl req -new -x509 -nodes -days 36500 -subj "/CN=DKMS module signing key" \ -newkey rsa:2048 -keyout "$mok_signing_key" \ -outform DER -out "$mok_certificate" > /dev/null 2>&1 fi https://salsa.debian.org/debian/dkms/-/blob/debian/3.0.8-3/dkms_framework.conf # Location of the key and certificate files used for Secure boot. # mok_signing_key can also be a "pkcs11:..." string for PKCS#11 engine, as # long as the sign_file program supports it. # (default: /var/lib/dkms): # mok_signing_key=/var/lib/dkms/mok.key # mok_certificate=/var/lib/dkms/mok.pub Thus for Debian the the MOK key is generated by dkms on first dkms build, in /var/lib/dkms, or points the mok_signing_key and mok_signing_certificate defined by the user in /etc/dkms/framework.conf So I conclude that the dkms part is nearly done. Only it does not work (at least on my box due to dkms looking for the sign-file kernel scipt at the wrong location) but the most critical issue is that the way it is done it is likely to break interactivity (it will ask on standard input for the key password while running dkms build, but what if dkms build is called while installing a module dkms package, or in a graphical package manager). At least the way it is done in ubuntu we have debhelper steps in shim- signed to ask for the password (and they are already there in debian too). I believe dkms is not the best suited to manage the MOK generation. shim-signed is a better fit. Dkms modules signing is another issue. Handling it in dkms at module build step is fine and should be kept. But when a new MOK key is generated or replaced by a new one the dkms modules should be signed anew with this new key. And dkms does not look like the best place to handle that use case. Cheers, Alban NB: The dkms prepare_signing step here fails per: + prepare_signing + '[' '!' '' ']' + case "$running_distribution" in + sign_file=/usr/lib/linux-kbuild-6.0.0-0.deb11/scripts/sign-file + echo 'Sign command: /usr/lib/linux-kbuild-6.0.0-0.deb11/scripts/sign- file' + [[ ! -f /usr/lib/linux-kbuild-6.0.0-0.deb11/scripts/sign-file ]] + echo 'Binary /usr/lib/linux-kbuild-6.0.0-0.deb11/scripts/sign-file not found, modules won'\''t be signed' + return ie the kernel path is wrong. The script is available in: /usr/lib/linux-kbuild-6.0/scripts/sign-file. So the MOK is not generated and the dkms modules are not signed.
