Implementing the use of DKMS and unsigned kernels in light of enforcing kernel signatures


In light of the need to allow only signed kernels by default, we need to make it possible for users to return to the previous behavior (using a signed kernel, but not enforcing signature checking on the kernel or modules).

This is especially necessary for users who require specific kernel modules built via dkms (since those would not be signed by the Canonical key), or users building their own kernel.

Use cases

John installs Ubuntu. He expects that the default installation will be sufficiently secure to protect him to some degree from malicious firmware (UEFI binaries), kernels, and modules.

Mallory wants to install Ubuntu, but her computer requires the use of the Yoyodyne graphics driver, which is only available as a DKMS package. She uses the installer to setup her system so that signature verification in shim will be disabled, but does not disable SecureBoot herself. That way, she can have 3D accelerated graphics on her system, but is still protected from a malicious shim or other UEFI binaries that may be unsigned or signed with untrusted keys.

Will has gone through the installer to set up his system and uses DKMS. Unfortunately, he forgot the password set during the installer. He is able to boot into Ubuntu anyway and uses UbuntuDrivers to re-do the module installation and configuration of MokManager.

Julia uses a DKMS module and a special keymap on her system. She has typed in a password in the installer which may not get typed the same way in MokManager due to keymap. She <this use case needs further definition, listed under Unresolved Issues>.


Any install in which DKMS use is detected.


Big Picture


Add ubiquity code to pass a password to mokutil to disable verification if DKMS use is detected. Also, add similar code to ubuntu-drivers for post-install setup of drivers requiring DKMS.


Data preservation and migration

Users who forget the password selected when setting up mokutil will still be able to reboot, however the kernel or modules which are not successfully verified will not be available (custom kernels will not be bootable (but we don't install custom kernels at install time) and DKMS modules will not be loaded (so some features may be unavailable).

Unresolved issues

  • How to handle keymap for password entry.



See Launchpad blueprint foundations-x-installing-unsigned-secureboot



Spec/InstallingUnsignedSecureBoot (last edited 2016-01-07 21:37:11 by vorlon)