Public bug reported:
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
behaviors:
* 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
challenge.
* 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 keyring
...
[ 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:
olddecodes=io+mem,decodes=none:owns=none
[ 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.
** Affects: linux (Ubuntu)
Importance: Undecided
Status: Incomplete
** Attachment added: "apport data from affected system"
https://bugs.launchpad.net/bugs/1798863/+attachment/5203120/+files/apport.linux-image-4.18.0-10-generic.c_cz4acm.apport
** Description changed:
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
behaviors:
* 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
challenge.
* 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
keyring
+ [ 4.234093] Loaded UEFI:MokListRT cert 'nvidia-installer generated
signing key: 90c957eb56dfb04d8734d54fb614ef5af6c69318' linked to secondary sys
keyring
...
- [ 6.628452] nvidia: module verification failed: signature and/or required
key missing - tainting kernel
+ [ 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:
olddecodes=io+mem,decodes=none:owns=none
- [ 6.737216] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 410.66 Wed
Oct 10 12:01:53 CDT 2018 (using threaded interrupts)
+ [ 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:
olddecodes=io+mem,decodes=none:owns=none
+ [ 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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1798863
Title:
18.10 kernel does not appear to validate kernel module signatures
correctly
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1798863/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
