Currently, if dkms is installed, shim-signed prompts to disable
kernel/module verification on next boot on some trigger events - to
ensure the system will successfully boot (something, not necessarily
untampered with) after a kernel upgrade.

According to Vorlon, in Ubuntu:
"that's since been superseded by code to instead generate and enroll a
MOK key and sign all dkms modules with it."

This sounds like a very useful feature that would be worth bringing into Debian.

(Thomas I hope you don't mind I put you in the Cc)

Leif Lindholm wrote:

I'd like to expand on this. When I install upstream (Oracle's)
virtualbox-6.1 then the package tries to compile and sign the required
virtualbox modules and fails due to not being able to sign them.

As far as I understand the code, the upstream virtualbox-6.1 package
expects the MOK keys to be at:

     # grep "^DEB_.*KEY=" /usr/lib/virtualbox/vboxdrv.sh
     DEB_PUB_KEY=/var/lib/shim-signed/mok/MOK.der
     DEB_PRIV_KEY=/var/lib/shim-signed/mok/MOK.priv

On a Ubuntu box (I checked on a focal) the keys are there:

I just updated the instructions accordingly with a pointer to this bug
report in case Debian would generate the MOK key automatically
in the future.
*t

I was the one who wrote them, after *A LOT* of research about it on the
internet. It was hard to find, really.

I just explained how to sign, with no intention to have this automated
(at the time), so no wonder there's no standard path...

Please go ahead, and explain that this is the Ubuntu path.

Well, to begin with, I wonder why the upstream virtualbox package is
pushing its compiled modules at the wrong location, but yeah, sure!

Hopefully, we can have the automation to sign DKMS modules in a non-leaf
package. I would strongly suggest we get a package with a very explicit
name in it, like "dkms-automatic-mok-signing" so it would do the work. I
would absolutely *not* go the path of disabling secure boot when a DKMS
module gets installed...

That's only suggestion, and I'm not volunteering, so that's only my 2
cents of comments... :)

Cheers,

Thomas Goirand (zigo)

I did not intend my characterisation of the instructions as a critique
of your work. I am extremely happy that you actually *did* the work for
all of us so we can stand on the shoulders of what you did. Very much +1
and many thanks really!!!

(And thanks & cheers to the Debian EFI Team as well :-D !!!!)

Done.

I guess one can always talk to upstream...

Since I have not looked further I am *guessing* that Ubuntu does
the automatic creation of the MOK key in the shim-signed package. So I
think it should be possible to lift Ubuntu's work out of there and also
put it into the shim-signed package, into postinst or so.

*t

No worries, I didn't take it this way! :)

As I understand, doing updates of shim-signed requires a signature from
Microsoft, so probably it's not the best place to do some change.

As for module automatic signatures, maybe this could go into the dkms
package itself, with some kind of configuration? Again, just a
suggestion... :)

Cheers,

Thomas Goirand (zigo)

On Thu, 18 Nov 2021 13:32:58 +0100 Thomas Goirand <zigo@debian.org> wrote:
(...)
non-leaf
explicit
work. I
DKMS
the
think
put it
from


https://salsa.debian.org/efi-team/shim-signed/-/tree/master/
The efi binaries are signed but not the package itself. Modifying the
package postinst and its update-secureboot-policy script are fine.

https://git.launchpad.net/~ubuntu-core-dev/shim/+git/shim-signed/tree/openssl.cnf
https://git.launchpad.net/~ubuntu-core-dev/shim/+git/shim-signed/tree/update-secureboot-policy
This ubuntu update-secureboot-policy has a --new-key flag to generate
the MOK in /var/lib/shim-signed/mok/.

https://git.launchpad.net/~ubuntu-core-dev/shim/+git/shim-signed/tree/debian/shim-signed.postinst
calls update-secureboot-policy --new-key on configure. It also sign the
dkms modules.


Cheers,
Alban

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.

Dear Maintainers,

Recently I upgraded Ubuntu 22.04 to Debian 12 Bookworm.
I used out-of-tree driver 88XXau for my USB WiFi adapter,
so with DKMS build I hit the behavior described in this bug,
that is, upgraded DKMS created its own key pair in /var/lib/dkms
and ignored already-enrolled MOK stored in /var/lib/shim-signed/mok/ .

So I got "Key was rejected by service" when I tried to modprobe the rebuilt module.

To resolve this problem, I just symlinked them into /var/lib/dkms :

ln -sf /var/lib/shim-signed/mok/MOK.priv /var/lib/dkms/mok.key
ln -sf /var/lib/shim-signed/mok/MOK.der /var/lib/dkms/mok.pub

After that, I uninstalled/unbuilt this module and reinstalled it
using appropriate dkms command-line options.
And to my great joy, the rebuilt module was successfully modprobed into the kernel,
even without requiring a reboot.

So it would be really useful for DKMS, when it is being upgraded over some previous version,
to inherit MOK created by shim-signed and to avoid creation of it own MOK.