kernel-packages team mailing list archive

[Steve Langasek <steve.langasek@xxxxxxxxxxxxx>]

Hello Mathieu, or anyone else affected,

Accepted dkms into wily-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/dkms/2.2.0.3-2ubuntu6.2 in a few
hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to
enable and use -proposed.  Your feedback will aid us getting this update
out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, and change the tag
from verification-needed to verification-done. If it does not fix the
bug for you, please add a comment stating that, and change the tag to
verification-failed.  In either case, details of your testing will help
us make a better decision.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance!

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to dkms in Ubuntu.
https://bugs.launchpad.net/bugs/1574727

Title:
  [SRU] Enforce using signed kernels and modules on UEFI

Status in dkms package in Ubuntu:
  Fix Released
Status in efibootmgr package in Ubuntu:
  Fix Released
Status in efivar package in Ubuntu:
  Fix Released
Status in grub2 package in Ubuntu:
  New
Status in grub2-signed package in Ubuntu:
  New
Status in mokutil package in Ubuntu:
  Fix Released
Status in shim package in Ubuntu:
  New
Status in shim-signed package in Ubuntu:
  Fix Released
Status in dkms source package in Precise:
  New
Status in efibootmgr source package in Precise:
  Invalid
Status in efivar source package in Precise:
  Fix Committed
Status in grub2 source package in Precise:
  New
Status in grub2-signed source package in Precise:
  New
Status in mokutil source package in Precise:
  Fix Committed
Status in shim source package in Precise:
  New
Status in shim-signed source package in Precise:
  In Progress
Status in dkms source package in Trusty:
  New
Status in efibootmgr source package in Trusty:
  Invalid
Status in efivar source package in Trusty:
  Fix Committed
Status in grub2 source package in Trusty:
  New
Status in grub2-signed source package in Trusty:
  New
Status in mokutil source package in Trusty:
  Fix Committed
Status in shim source package in Trusty:
  New
Status in shim-signed source package in Trusty:
  In Progress
Status in dkms source package in Wily:
  Fix Committed
Status in efibootmgr source package in Wily:
  Fix Released
Status in efivar source package in Wily:
  Fix Released
Status in grub2 source package in Wily:
  New
Status in grub2-signed source package in Wily:
  New
Status in mokutil source package in Wily:
  Fix Committed
Status in shim source package in Wily:
  New
Status in shim-signed source package in Wily:
  Fix Committed
Status in dkms source package in Xenial:
  Fix Released
Status in efibootmgr source package in Xenial:
  Fix Released
Status in efivar source package in Xenial:
  Fix Released
Status in grub2 source package in Xenial:
  Fix Committed
Status in grub2-signed source package in Xenial:
  Fix Committed
Status in mokutil source package in Xenial:
  Fix Released
Status in shim source package in Xenial:
  New
Status in shim-signed source package in Xenial:
  Fix Committed

Bug description:
  [Rationale]
  Secure Boot is good. We want to be able to validate that as much as possible of the boot process happens with signed binaries; from our shim (the part that is loaded by the EFI firmware itself), down to grub2, the kernel, and even loaded modules.

  [Impact]
  All our users booting in UEFI; on all supported releases.

  [Test cases]
  https://docs.google.com/spreadsheets/d/1GbyQDb4-sRv7OlIpbISiwVJ2ARHP3AkG2HbPTRk7p-E/edit#gid=0

  Test cases here are separated by the components that need to be
  changed:

  = mokutil =

  Adding a MOK key:
  1) Install system
  2) Run 'mokutil --import <file.der>' to import a signing certificate.
  3) On reboot; validate MOK prompts for new MOK key to add.

  Toggling Secure Boot state:
  1) Install system
  2) mokutil --enable-validation    or    mokutil --disable-validation
  3) Validate that on reboot MOK prompts to change Secure Boot state.

  Listing keys:
  1) mokutil --list-enrolled
  -- should list keys previously enrolled, and Microsoft keys on systems that are configured with them for factory Secure Boot.

  
  = efivar =

  libefivar0 gets tested via the use of mokutil. Since it is a library
  with no directly usable binaries; we rely on mokutil / sbsigntool /
  efibootmgr to do testing.

  1) Run efibootmgr -v ; verify it lists BootEntries.
  2) Run efibootmgr -c -L ubuntu2 -l \\EFI\\ubuntu\\shimx64.efi ; verify that on reboot; you can get into a boot menu that will list 'ubuntu2', and that picking that boot entry boots into Ubuntu.

  
  = shim-signed =

  1) Install system; upgrade to new packages
  1b) Verify /proc/sys/kernel/secure_boot shows 1.
  1c) Verify /proc/sys/kernel/moksbstate_disabled shows 0.
  2) Run 'sudo update-secureboot-policy'; validate that it prompts to disable Secure Boot if it's not already disabled.
  3) Run 'sudo update-secureboot-policy'; validate you are not prompted again to disable Secure Boot.
  4) Reboot; follow MOK steps to disable Secure Boot.
  4b) Verify /proc/sys/kernel/secure_boot shows 1.
  4c) Verify /proc/sys/kernel/moksbstate_disabled shows 1.
  5) Run 'sudo update-secureboot-policy --enable'; validate you are prompted to enable Secure Boot.
  6) Reboot; follow MOK steps to re-enable Secure Boot.
  6b) Verify /proc/sys/kernel/secure_boot shows 1.
  6c) Verify /proc/sys/kernel/moksbstate_disabled shows 0.

  
  = grub2 =

  Booting signed kernels:
  1) Try to boot a custom kernel
  2) Verify that the kernel will not be loaded by grub (you should see an error message about the signature)

  Prompting on upgrade:
  0) On a system that runs a dkms module (such as r8168-dkms, rtl8812au-dkms, ndiswrapper-dkms, bbswitch-dkms, etc.)
  1) Make sure that validation is enabled and reboot: 'sudo mokutil --enable-validation && sudo reboot'
  2) Upgrade to the new grub2 package (you may need to download the updated package beforehand)
  3) Validate that grub2 prompts you to disable shim validation.

  
  = dkms =

  Prompting for dkms on install:
  1) Install r8168-dkms
  2) Verify that you're asked to disable shim validation, and walked through the process via debconf prompts.

  Prompting for dkms on upgrade
  0) On a system that runs a dkms module (such as r8168-dkms, rtl8812au-dkms, ndiswrapper-dkms, bbswitch-dkms, etc.)
  1) Make sure that validation is enabled and reboot: 'sudo mokutil --enable-validation && reboot'
  2) Upgrade to the new dkms package (you may need to download the updated package beforehand)
  3) Validate that dkms prompts you to disable shim validation.

  
  = shim =

  Booting:
  -> Validate that it allows booting grubx64.efi signed with the old key.
  -> Validate that it allows booting grubx64.efi signed with the new key.

  Validation toggle:
  0) Boot the system; verify if /sys/firmware/efi/efivars/MokSBStateRT-* is present;
  If MokSBStateRT is preset:
  1) sudo mokutil --enable-validation && sudo reboot
  2) Validate that Mok asks you if you want to enable validation
  Otherwise:
  1) sudo mokutil --disable-validation && sudo reboot
  2) Validate that Mok asks you if you want to disable validation
  Finally:
  3) Complete the process to toggle validation state, reboot, and verify whether MokSBStateRT is present.
  4) Run mokutil again to toggle validation back to its former state.

  [Regression Potential]
  Issues to watch out for:
  - (dkms) not prompting on upgrade of a dkms package/dkms itself if validation is currently enabled (provided debconf does not have dkms/disable_secureboot seen and set to false)
  - (dkms, on new shim) prompting unnecessarily if validation is already disabled
  - (grub) not prompting on upgrade ...
  - (grub) not prompting on upgrade across releases if validation is disabled; without the applied SRU on original release.
  - (grub, on new shim) prompting unecessarily ...
  - (shim) failing to boot on some firmware that doesn't correctly follow specification
  - (shim) failing to load a properly-signed grub
  - (shim) accepting to load a badly-signed grub

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dkms/+bug/1574727/+subscriptions