This bug was erroneously marked for verification in bionic; verification
is not required and verification-needed-bionic is being removed.

** Tags removed: verification-needed-bionic
** Tags added: kernel-fixup-verification-needed-bionic verification-done-bionic

You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.

  18.10 kernel does not appear to validate kernel module signatures

Status in linux package in Ubuntu:
  In Progress
Status in shim package in Ubuntu:
Status in linux source package in Cosmic:
  Fix Released
Status in shim source package in Cosmic:

Bug description:
  SRU Justification

  Impact: An bug in the secure boot lockdown patches in the 18.10 kernel
  causes the results of module signature verification to be ignored,
  allowing modules with no signature or an invalid signature to be
  loaded. A second bug results in the MOK not being trusted for signing
  modules, but this bug has been masked by the first bug.

  Fix: These bugs should be fixed together to avoid regressions in dkms
  module loading under secure boot. First, fix the latter bug by
  trusting keys in the kernel's secondary keyring for module signing.
  Then fix the former bug by removing code related to trusting IMA
  signatures for loading modules under kernel lockdown.

  Test Case: Confirm the following behavior under kernel lockdown:

    1) Unsigned modules cannot be loaded.

    2) Modules signed with an untrusted key cannot be loaded.

    3) Modules signed with the kernel's ephemeral build-time key can be

    4) Modules signed with a MOK which has been enrolled with shim can
  be loaded.

  I have tested to verify these conditions with the proposed fixes.

  Regression Potential: This restores the behavior from previous Ubuntu
  releases, so no regressions are expected wrt those releases. In some
  cases modules that were loading under lockdown might no longer load,
  but this is the intended behavior.


  On a system with Ubuntu 18.10, with secure boot enabled, and a key
  enrolled in the MOK database, I am observing the following peculiar

  * Signature verification appears to be disabled, and cannot be enabled again. 
It appeared to be enabled previously, as loading of unsigned modules was 
failing, and `mokutil --enable-validation` runs without incident; however, upon 
the next boot when attempting to confirm the change, MokManager prints an error 
message "Unable to delete Secure Boot state" after completing the password 
  * As a result of signature verification being disabled, modules signed with 
untrusted keys taint the kernel instead of failing to load outright.
  * Regardless of signature verification being enabled or not, it seems that 
the key enrolled in the MOK is not being used for validating kernel module 
signatures. Modules signed with the key still fail the signature verification 
test and taint the kernel, even though the key is visible in the output of 
`mokutil --list-enrolled`, and testing the key with `mokutil --test-key` shows 
that it's enrolled. Also, a message acknowledging the key appears in dmesg: 
Loaded UEFI:MokListRT cert 'nvidia-installer generated signing key: 
90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys keyring
  * Also, somewhat strangely, in this state with module signature verification 
not being enforced, attempting to load a completely unsigned kernel module 
suceeds, and doesn't even log a kernel message about a missing/invalid 
signature, or taint the kernel.

  Apport report attached, which includes dmesg log showing the kernel
  acknowledging the key enrolled in the MOK database, and a signature
  verification failure and subsequent successful loading of a module
  signed with that key:

   [    4.234093] Loaded UEFI:MokListRT cert 'nvidia-installer generated 
signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys 
   [    6.628452] nvidia: module verification failed: signature and/or required 
key missing - tainting kernel
   [    6.637252] nvidia-nvlink: Nvlink Core is being initialized, major device 
number 238
   [    6.637507] nvidia 0000:01:00.0: enabling device (0006 -> 0007)
   [    6.637620] nvidia 0000:01:00.0: vgaarb: changed VGA decodes: 
   [    6.737216] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  410.66  Wed 
Oct 10 12:01:53 CDT 2018 (using threaded interrupts)

  This system dual-boots Ubuntu 18.04 and Ubuntu 18.10: when booted into Ubuntu 
18.04, signatures made with the same key are recognized as valid. Hence, I 
suspect that something changed in the Ubuntu 18.10 kernel which is causing 
signature verification to function in an unexpected way.
  ProblemType: Bug
  ApportVersion: 2.20.10-0ubuntu13
  Architecture: amd64
   /dev/snd/controlC0:  danix      1729 F.... pulseaudio
  DistroRelease: Ubuntu 18.10
  InstallationDate: Installed on 2018-10-23 (0 days ago)
  InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 
  NonfreeKernelModules: nvidia_uvm nvidia
  Package: linux (not installed)
   PATH=(custom, no user)
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.18.0-10-generic 
root=/dev/mapper/ubuntu--vg-root ro quiet splash nouveau.modeset=0
  ProcVersionSignature: Ubuntu 4.18.0-10.11-generic 4.18.12
   linux-restricted-modules-4.18.0-10-generic N/A
   linux-backports-modules-4.18.0-10-generic  N/A
   linux-firmware                             1.175
  Tags:  cosmic
  Uname: Linux 4.18.0-10-generic x86_64
  UnreportableReason: This report is about a package that is not installed.
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
  _MarkForUpload: False 03/20/2018
  dmi.bios.vendor: HP
  dmi.bios.version: P70 Ver. 01.18 8270
  dmi.board.vendor: HP
  dmi.board.version: KBC Version 46.67
  dmi.chassis.type: 10
  dmi.chassis.vendor: HP
dmi:bvnHP:bvrP70Ver.01.18:bd03/20/2018:svnHP:pn:pvr:rvnHP:rn8270:rvrKBCVersion46.67:cvnHP:ct10:cvr: 103C_5336AN HP ZBook
  dmi.sys.vendor: HP

To manage notifications about this bug go to:

Mailing list:
Post to     :
Unsubscribe :
More help   :

Reply via email to