[Kernel-packages] [Bug 1798863] Re: 18.10 kernel does not appear to validate kernel module signatures correctly
** Tags added: cscc -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: Fix Released Status in shim package in Ubuntu: Invalid Status in linux source package in Cosmic: Fix Released Status in shim source package in Cosmic: Invalid 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 loaded. 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 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 :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :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. --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /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 (2
[Kernel-packages] [Bug 1798863] Re: 18.10 kernel does not appear to validate kernel module signatures correctly
** Changed in: linux (Ubuntu) Status: In Progress => Fix Released -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: Fix Released Status in shim package in Ubuntu: Invalid Status in linux source package in Cosmic: Fix Released Status in shim source package in Cosmic: Invalid 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 loaded. 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 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 :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :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. --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: danix 1729 F pulseaudio DistroRelease: Ubuntu 18.10 InstallationDate: Installed on 2018-10-23 (0 days ago) InstallationMedia:
[Kernel-packages] [Bug 1798863] Re: 18.10 kernel does not appear to validate kernel module signatures correctly
That is unlikely to be true. Please file a new bug report and describe in your own words what is happening and why you believe it is a bug. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: In Progress Status in shim package in Ubuntu: Invalid Status in linux source package in Cosmic: Fix Released Status in shim source package in Cosmic: Invalid 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 loaded. 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 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 :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :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. --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: danix 1729 F pulseaudio DistroRelease: Ubuntu 18.10 Installa
[Kernel-packages] [Bug 1798863] Re: 18.10 kernel does not appear to validate kernel module signatures correctly
Still facing the same problem! Machine: MSI GV62 7RD Processor: Intel® Core™ i7-7700HQ CPU @ 2.80GHz × 8 Graphics: GeForce GTX 1050/PCIe/SSE2 Operating System: Ubuntu 18.10 Kernel: 4.18.0-15-generic -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: In Progress Status in shim package in Ubuntu: Invalid Status in linux source package in Cosmic: Fix Released Status in shim source package in Cosmic: Invalid 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 loaded. 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 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 :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :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. --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: danix 172
[Kernel-packages] [Bug 1798863] Re: 18.10 kernel does not appear to validate kernel module signatures correctly
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. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: In Progress Status in shim package in Ubuntu: Invalid Status in linux source package in Cosmic: Fix Released Status in shim source package in Cosmic: Invalid 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 loaded. 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 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 :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :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. --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 AudioDevicesInUse: USER
[Kernel-packages] [Bug 1798863] Re: 18.10 kernel does not appear to validate kernel module signatures correctly
I'm confused about the above message. This bug never affected the kernel in Bionic AFAIK. Or is this referring to the HWE kernel for Bionic from Cosmic for 18.04.2? In that case, why isn't this change already included in the HWE kernel as it was imported from Cosmic, rather than needing to be brought in through -proposed first? -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: In Progress Status in shim package in Ubuntu: Invalid Status in linux source package in Cosmic: Fix Released Status in shim source package in Cosmic: Invalid 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 loaded. 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 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 :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :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. --- ProblemType: Bug ApportVersion: 2.2
[Kernel-packages] [Bug 1798863] Re: 18.10 kernel does not appear to validate kernel module signatures correctly
This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed- bionic' to 'verification-done-bionic'. If the problem still exists, change the tag 'verification-needed-bionic' to 'verification-failed- bionic'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: verification-needed-bionic -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: In Progress Status in shim package in Ubuntu: Invalid Status in linux source package in Cosmic: Fix Released Status in shim source package in Cosmic: Invalid 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 loaded. 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 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 :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :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-
[Kernel-packages] [Bug 1798863] Re: 18.10 kernel does not appear to validate kernel module signatures correctly
This bug was fixed in the package linux - 4.18.0-12.13 --- linux (4.18.0-12.13) cosmic; urgency=medium * linux: 4.18.0-12.13 -proposed tracker (LP: #1802743) * [FEAT] Guest-dedicated Crypto Adapters (LP: #1787405) - s390/zcrypt: Add ZAPQ inline function. - s390/zcrypt: Review inline assembler constraints. - s390/zcrypt: Integrate ap_asm.h into include/asm/ap.h. - s390/zcrypt: fix ap_instructions_available() returncodes - KVM: s390: vsie: simulate VCPU SIE entry/exit - KVM: s390: introduce and use KVM_REQ_VSIE_RESTART - KVM: s390: refactor crypto initialization - s390: vfio-ap: base implementation of VFIO AP device driver - s390: vfio-ap: register matrix device with VFIO mdev framework - s390: vfio-ap: sysfs interfaces to configure adapters - s390: vfio-ap: sysfs interfaces to configure domains - s390: vfio-ap: sysfs interfaces to configure control domains - s390: vfio-ap: sysfs interface to view matrix mdev matrix - KVM: s390: interface to clear CRYCB masks - s390: vfio-ap: implement mediated device open callback - s390: vfio-ap: implement VFIO_DEVICE_GET_INFO ioctl - s390: vfio-ap: zeroize the AP queues - s390: vfio-ap: implement VFIO_DEVICE_RESET ioctl - KVM: s390: Clear Crypto Control Block when using vSIE - KVM: s390: vsie: Do the CRYCB validation first - KVM: s390: vsie: Make use of CRYCB FORMAT2 clear - KVM: s390: vsie: Allow CRYCB FORMAT-2 - KVM: s390: vsie: allow CRYCB FORMAT-1 - KVM: s390: vsie: allow CRYCB FORMAT-0 - KVM: s390: vsie: allow guest FORMAT-0 CRYCB on host FORMAT-1 - KVM: s390: vsie: allow guest FORMAT-1 CRYCB on host FORMAT-2 - KVM: s390: vsie: allow guest FORMAT-0 CRYCB on host FORMAT-2 - KVM: s390: device attrs to enable/disable AP interpretation - KVM: s390: CPU model support for AP virtualization - s390: doc: detailed specifications for AP virtualization - KVM: s390: fix locking for crypto setting error path - KVM: s390: Tracing APCB changes - s390: vfio-ap: setup APCB mask using KVM dedicated function - [Config:] Enable CONFIG_S390_AP_IOMMU and set CONFIG_VFIO_AP to module. * Bypass of mount visibility through userns + mount propagation (LP: #1789161) - mount: Retest MNT_LOCKED in do_umount - mount: Don't allow copying MNT_UNBINDABLE|MNT_LOCKED mounts * CVE-2018-18955: nested user namespaces with more than five extents incorrectly grant privileges over inode (LP: #1801924) // CVE-2018-18955 - userns: also map extents in the reverse map to kernel IDs * kdump fail due to an IRQ storm (LP: #1797990) - SAUCE: x86/PCI: Export find_cap() to be used in early PCI code - SAUCE: x86/quirks: Add parameter to clear MSIs early on boot - SAUCE: x86/quirks: Scan all busses for early PCI quirks * crash in ENA driver on removing an interface (LP: #1802341) - SAUCE: net: ena: fix crash during ena_remove() * Ubuntu 18.04.1 - [s390x] Kernel panic while stressing network bonding (LP: #1797367) - s390/qeth: reduce hard-coded access to ccw channels - s390/qeth: sanitize strings in debug messages * Add checksum offload and TSO support for HiNIC adapters (LP: #1800664) - net-next/hinic: add checksum offload and TSO support * smartpqi updates for ubuntu 18.04.2 (LP: #1798208) - scsi: smartpqi: improve handling for sync requests - scsi: smartpqi: improve error checking for sync requests - scsi: smartpqi: add inspur advantech ids - scsi: smartpqi: fix critical ARM issue reading PQI index registers - scsi: smartpqi: bump driver version to 1.1.4-130 * [GLK/CLX] Enhanced IBRS (LP: #1786139) - x86/speculation: Remove SPECTRE_V2_IBRS in enum spectre_v2_mitigation - x86/speculation: Support Enhanced IBRS on future CPUs * Enable keyboard wakeup for S2Idle laptops (LP: #1798552) - Input: i8042 - enable keyboard wakeups by default when s2idle is used * Overlayfs in user namespace leaks directory content of inaccessible directories (LP: #1793458) // CVE-2018-6559 - SAUCE: overlayfs: ensure mounter privileges when reading directories * Update ENA driver to version 2.0.1K (LP: #1798182) - net: ena: remove ndo_poll_controller - net: ena: fix auto casting to boolean - net: ena: minor performance improvement - net: ena: complete host info to match latest ENA spec - net: ena: introduce Low Latency Queues data structures according to ENA spec - net: ena: add functions for handling Low Latency Queues in ena_com - net: ena: add functions for handling Low Latency Queues in ena_netdev - net: ena: use CSUM_CHECKED device indication to report skb's checksum status - net: ena: explicit casting and initialization, and clearer error handling - net: ena: limit refill Rx threshold to 256 to avoid latency issues - net: ena: change rx copybreak default to reduce kernel memory pressure - net: ena: remove redundant p
[Kernel-packages] [Bug 1798863] Re: 18.10 kernel does not appear to validate kernel module signatures correctly
Based on the above comments, I'm marking verification done for Cosmic. Thank you! ** Tags removed: verification-needed-cosmic ** Tags added: verification-done-cosmic -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: In Progress Status in shim package in Ubuntu: Invalid Status in linux source package in Cosmic: Fix Committed Status in shim source package in Cosmic: Invalid 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 loaded. 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 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 :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :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. --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: danix 1729 F pulseaudio DistroRelea
[Kernel-packages] [Bug 1798863] Re: 18.10 kernel does not appear to validate kernel module signatures correctly
Daniel: A message is printed for only the first time a module signature verification fails for any reason, so if you tested the "signed with key not enrolled in the MOK" and then "not signed" cases in the same boot you will only see a message for the first one. If you reboot and then retest the "not signed" case by itself you should see a message. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: In Progress Status in shim package in Ubuntu: Invalid Status in linux source package in Cosmic: Fix Committed Status in shim source package in Cosmic: Invalid 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 loaded. 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 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 :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :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. --- ProblemType: Bug
[Kernel-packages] [Bug 1798863] Re: 18.10 kernel does not appear to validate kernel module signatures correctly
Hi Daniel Dadap, Thank you for your feedback. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: In Progress Status in shim package in Ubuntu: Invalid Status in linux source package in Cosmic: Fix Committed Status in shim source package in Cosmic: Invalid 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 loaded. 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 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 :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :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. --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /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 Cutt
[Kernel-packages] [Bug 1798863] Re: 18.10 kernel does not appear to validate kernel module signatures correctly
Just to confirm, this is with the 4.18.0-12-generic x86_64 kernel from cosmic-proposed. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: In Progress Status in shim package in Ubuntu: Invalid Status in linux source package in Cosmic: Fix Committed Status in shim source package in Cosmic: Invalid 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 loaded. 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 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 :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :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. --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: danix 1729 F pulseaudio DistroRelease: Ubuntu 18.10 InstallationDate: Installed on 2018-10-23 (0 days ago) Ins
[Kernel-packages] [Bug 1798863] Re: 18.10 kernel does not appear to validate kernel module signatures correctly
Yes, I do see the expected behavior now with signed modules, both when the signing key is enrolled in the MOK (module loads, no verification error) and when it is not enrolled in the MOK (module fails to load due to verification error.) However, the behavior is not quite what I expect when a module is unsigned. The module fails to load, which is expected, but there is no error message in dmesg indicating a missing key, which can make it tricky to determine why the module failed to load, since the failure message printed by modprobe/insmod is simply "Operation not permitted". (It seems the ENOKEY failure is not getting propagated to the user-facing tool.) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: In Progress Status in shim package in Ubuntu: Invalid Status in linux source package in Cosmic: Fix Committed Status in shim source package in Cosmic: Invalid 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 loaded. 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 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 :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :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)
[Kernel-packages] [Bug 1798863] Re: 18.10 kernel does not appear to validate kernel module signatures correctly
Hi Thanh Tung, Please do not change manually a series release task to 'Fix Released', that is done automatically by a bot when the package hits -updates. Thank you. ** Changed in: linux (Ubuntu Cosmic) Status: Fix Released => Fix Committed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: In Progress Status in shim package in Ubuntu: Invalid Status in linux source package in Cosmic: Fix Committed Status in shim source package in Cosmic: Invalid 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 loaded. 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 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 :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :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. --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 AudioDevicesInUse: USERPID AC
[Kernel-packages] [Bug 1798863] Re: 18.10 kernel does not appear to validate kernel module signatures correctly
Hi Daniel Dadap, Could you please verify if the Cosmic kernel currently in -proposed fixes the issue? Thank you. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: In Progress Status in shim package in Ubuntu: Invalid Status in linux source package in Cosmic: Fix Committed Status in shim source package in Cosmic: Invalid 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 loaded. 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 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 :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :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. --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: danix 1729 F pulseaudio DistroRelease: Ubuntu 18.10 InstallationDate: Installed on 20
[Kernel-packages] [Bug 1798863] Re: 18.10 kernel does not appear to validate kernel module signatures correctly
** Changed in: linux (Ubuntu Cosmic) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: In Progress Status in shim package in Ubuntu: Invalid Status in linux source package in Cosmic: Fix Released Status in shim source package in Cosmic: Invalid 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 loaded. 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 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 :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :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. --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: danix 1729 F pulseaudio DistroRelease: Ubuntu 18.10 InstallationDate: Installed on 2018-10-23 (0 days ago) Installati
[Kernel-packages] [Bug 1798863] Re: 18.10 kernel does not appear to validate kernel module signatures correctly
This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed- cosmic' to 'verification-done-cosmic'. If the problem still exists, change the tag 'verification-needed-cosmic' to 'verification-failed- cosmic'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: verification-needed-cosmic -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: In Progress Status in shim package in Ubuntu: Invalid Status in linux source package in Cosmic: Fix Committed Status in shim source package in Cosmic: Invalid 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 loaded. 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 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 :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :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
[Kernel-packages] [Bug 1798863] Re: 18.10 kernel does not appear to validate kernel module signatures correctly
** Changed in: linux (Ubuntu Cosmic) Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: In Progress Status in shim package in Ubuntu: Invalid Status in linux source package in Cosmic: Fix Committed Status in shim source package in Cosmic: Invalid 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 loaded. 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 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 :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :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. --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: danix 1729 F pulseaudio DistroRelease: Ubuntu 18.10 InstallationDate: Installed on 2018-10-23 (0 days ago) Installati
[Kernel-packages] [Bug 1798863] Re: 18.10 kernel does not appear to validate kernel module signatures correctly
** Description changed: + 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 + loaded. + + 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 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 :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :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. - --- + --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 AudioDevicesInUse: - USERPID ACCESS COMMAND - /dev/snd/controlC0: danix 1729 F pulseaudio + USERPID ACCESS COMMAND + /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 (20181017.3) NonfreeKernelModules: nvidia_uvm nvidia Package: linux (not installed) ProcEnviron: - TERM=xterm-256color - PATH=(custom, no user) - XDG_RUNTIME_DIR= - LANG=en_US.UTF-8 - SHELL=/bin/bash + TERM=xterm-256color + PATH=(custom, no user) + XDG_RUNTIME_DIR= + LANG=en_US.UTF-8 + SHELL=/bin/bash ProcFB: 0 inteldrmfb
[Kernel-packages] [Bug 1798863] Re: 18.10 kernel does not appear to validate kernel module signatures correctly
Cool, glad you were able to track down the problems. Sorry if my report that module signature verification was disabled and couldn't be re- enabled was misleading. That's what I thought was happening; I didn't think to imagine that the enforcement of the "valid signature required" policy wasn't taking place at all. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: In Progress Status in shim package in Ubuntu: Invalid Status in linux source package in Cosmic: In Progress Status in shim source package in Cosmic: Invalid Bug description: 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 :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :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. --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /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 (20181017.3) NonfreeKernelModules: nvidia_uvm nvidia Package: linux (not installed) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash 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 RelatedPackageVersions: 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 dmi.bios.date: 03/20/2018 dmi.bios.vendor: HP dmi.bios.version: P70 Ver. 01.18 dmi.board.name: 8270 dmi.board.vendor: HP dmi.board.version: KBC Version 46.67 dmi.chassis.type
[Kernel-packages] [Bug 1798863] Re: 18.10 kernel does not appear to validate kernel module signatures correctly
Use CVE-2018-18653. ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-18653 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: In Progress Status in shim package in Ubuntu: Invalid Status in linux source package in Cosmic: In Progress Status in shim source package in Cosmic: Invalid Bug description: 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 :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :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. --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /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 (20181017.3) NonfreeKernelModules: nvidia_uvm nvidia Package: linux (not installed) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash 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 RelatedPackageVersions: 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 dmi.bios.date: 03/20/2018 dmi.bios.vendor: HP dmi.bios.version: P70 Ver. 01.18 dmi.board.name: 8270 dmi.board.vendor: HP dmi.board.version: KBC Version 46.67 dmi.chassis.type: 10 dmi.chassis.vendor: HP dmi.modalias: dmi:bvnHP:bvrP70Ver.01.18:bd03/20/2018:svnHP:pn:pvr:rvnHP:rn8270:rvrKBCVersion46.67:cvnHP:ct10:cvr: dmi.product.family: 103C_5336AN HP ZBook dmi.sys.vendor: HP To manage n
[Kernel-packages] [Bug 1798863] Re: 18.10 kernel does not appear to validate kernel module signatures correctly
I need to make a correction to the last sentence of my last comment. Signature verification is performed but the result is effectively ignored due to the configuration options mentioned earlier in that comment. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: In Progress Status in shim package in Ubuntu: Invalid Status in linux source package in Cosmic: In Progress Status in shim source package in Cosmic: Invalid Bug description: 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 :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :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. --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /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 (20181017.3) NonfreeKernelModules: nvidia_uvm nvidia Package: linux (not installed) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash 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 RelatedPackageVersions: 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 dmi.bios.date: 03/20/2018 dmi.bios.vendor: HP dmi.bios.version: P70 Ver. 01.18 dmi.board.name: 8270 dmi.board.vendor: HP dmi.board.version: KBC Version 46.67 dmi.chassis.type: 10 dmi.chassis.vendor: HP dmi.modalias: dmi:bvnHP:bvrP70Ver.01.18:bd03/20/2018:svnHP:pn:pvr:rvnHP:r
[Kernel-packages] [Bug 1798863] Re: 18.10 kernel does not appear to validate kernel module signatures correctly
I've requested a CVE for this issue. I wanted to provide some more context as other Linux distributions will likely be reading this bug report once the CVE assignment occurs. This flaw is introduced by certain configuration options in combination with this out-of-tree patch from the Lockdown patchset: https://git.launchpad.net/~ubuntu- kernel/ubuntu/+source/linux/+git/cosmic/commit/?id=03c7de9e956395f3b36f86f89b62780ad9501eef We do not force module signatures (CONFIG_MODULE_SIG_FORCE=n), we enable IMA-appraise (CONFIG_IMA_APPRAISE=y), and we do not use the built-in IMA secure_boot policy snippet by default. Therefore, no signature verification is performed when a module is loaded via the finit_module(2) syscall. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: In Progress Status in shim package in Ubuntu: Invalid Status in linux source package in Cosmic: In Progress Status in shim source package in Cosmic: Invalid Bug description: 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 :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :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. --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /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 (20181017.3) NonfreeKernelModules: nvidia_uvm nvidia Package: linux (not installed) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash 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 RelatedPackageVersions: 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 U
[Kernel-packages] [Bug 1798863] Re: 18.10 kernel does not appear to validate kernel module signatures correctly
I can clarify what's happening in the kernel. There are two bugs, and one is masking the other. The first bug is that we don't use the secondary keyring for verifying module signatures. The secondary keyring is where the MOK ends. The second bug is that we aren't enforcing that modules must be signed when under lockdown. So even though signature verification fails due to the first bug the module is still allowed to load. I have patches for both bugs. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: In Progress Status in shim package in Ubuntu: In Progress Status in linux source package in Cosmic: In Progress Status in shim source package in Cosmic: In Progress Bug description: 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 :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :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. --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /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 (20181017.3) NonfreeKernelModules: nvidia_uvm nvidia Package: linux (not installed) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash 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 RelatedPackageVersions: 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 dmi.bios.date: 03/20/2018 dmi.bios.
[Kernel-packages] [Bug 1798863] Re: 18.10 kernel does not appear to validate kernel module signatures correctly
Based on Seth's response there is no reason to suspect shim here. ** Changed in: shim (Ubuntu Cosmic) Status: In Progress => Invalid -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: In Progress Status in shim package in Ubuntu: Invalid Status in linux source package in Cosmic: In Progress Status in shim source package in Cosmic: Invalid Bug description: 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 :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :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. --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /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 (20181017.3) NonfreeKernelModules: nvidia_uvm nvidia Package: linux (not installed) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash 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 RelatedPackageVersions: 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 dmi.bios.date: 03/20/2018 dmi.bios.vendor: HP dmi.bios.version: P70 Ver. 01.18 dmi.board.name: 8270 dmi.board.vendor: HP dmi.board.version: KBC Version 46.67 dmi.chassis.type: 10 dmi.chassis.vendor: HP dmi.modalias: dmi:bvnHP:bvrP70Ver.01.18:bd03/20/2018:svnHP:pn:pvr:rvnHP:rn8270:rvrKBCVersion46.67:cvnHP:ct10:cvr: dmi.product.family: 103C_53
[Kernel-packages] [Bug 1798863] Re: 18.10 kernel does not appear to validate kernel module signatures correctly
Opening a task for shim; I want to check whether this is doing what it is supposed to, at least on a new install. ** Also affects: shim (Ubuntu) Importance: Undecided Status: New ** Changed in: shim (Ubuntu Cosmic) Status: New => In Progress ** Changed in: shim (Ubuntu Cosmic) Importance: Undecided => Medium ** Changed in: shim (Ubuntu Cosmic) Assignee: (unassigned) => Mathieu Trudel-Lapierre (cyphermox) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: In Progress Status in shim package in Ubuntu: In Progress Status in linux source package in Cosmic: In Progress Status in shim source package in Cosmic: In Progress Bug description: 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 :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :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. --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /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 (20181017.3) NonfreeKernelModules: nvidia_uvm nvidia Package: linux (not installed) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash 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 RelatedPackageVersions: 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 dmi.bios.date: 03/20/2018 dmi.bios.vendor: HP dmi.bios
[Kernel-packages] [Bug 1798863] Re: 18.10 kernel does not appear to validate kernel module signatures correctly
There's a bit I don't understand: "* 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." Sure, there are other issues at play here, but every test I've done of this has been working just fine, and at that point we're not actually talking to the kernel at all. Could we be hitting an issue with the firmware on this specific HP machine? Is this something you see on other hardware (if you can test)? If you toggle validation in 18.04, do things work then? I wonder if you're hitting an issue here due to versioning of the different EFI binaries; if you have 18.10 and 18.04 installed, I wonder which version of shim and mokmanager are actually being used. As for what happens at the kernel level, I don't know. If the MOK key is available there (it certainly seemed to be), then I concur there would have to be a bug in the keyring handling. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: In Progress Status in shim package in Ubuntu: In Progress Status in linux source package in Cosmic: In Progress Status in shim source package in Cosmic: In Progress Bug description: 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 :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :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. --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /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 (20181017.3) NonfreeKernelModules: nvidia_uvm nvidia Package: linux (not installed) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UT
[Kernel-packages] [Bug 1798863] Re: 18.10 kernel does not appear to validate kernel module signatures correctly
** Changed in: linux (Ubuntu Cosmic) Status: Confirmed => In Progress -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: In Progress Status in linux source package in Cosmic: In Progress Bug description: 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 :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :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. --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /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 (20181017.3) NonfreeKernelModules: nvidia_uvm nvidia Package: linux (not installed) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash 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 RelatedPackageVersions: 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 dmi.bios.date: 03/20/2018 dmi.bios.vendor: HP dmi.bios.version: P70 Ver. 01.18 dmi.board.name: 8270 dmi.board.vendor: HP dmi.board.version: KBC Version 46.67 dmi.chassis.type: 10 dmi.chassis.vendor: HP dmi.modalias: dmi:bvnHP:bvrP70Ver.01.18:bd03/20/2018:svnHP:pn:pvr:rvnHP:rn8270:rvrKBCVersion46.67:cvnHP:ct10:cvr: dmi.product.family: 103C_5336AN HP ZBook dmi.sys.vendor: HP To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1798863/+subscriptions
[Kernel-packages] [Bug 1798863] Re: 18.10 kernel does not appear to validate kernel module signatures correctly
** Changed in: linux (Ubuntu Cosmic) Status: Incomplete => Confirmed ** Changed in: linux (Ubuntu Cosmic) Assignee: (unassigned) => Seth Forshee (sforshee) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: Confirmed Status in linux source package in Cosmic: Confirmed Bug description: 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 :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :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. --- ProblemType: Bug ApportVersion: 2.20.10-0ubuntu13 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /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 (20181017.3) NonfreeKernelModules: nvidia_uvm nvidia Package: linux (not installed) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash 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 RelatedPackageVersions: 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 dmi.bios.date: 03/20/2018 dmi.bios.vendor: HP dmi.bios.version: P70 Ver. 01.18 dmi.board.name: 8270 dmi.board.vendor: HP dmi.board.version: KBC Version 46.67 dmi.chassis.type: 10 dmi.chassis.vendor: HP dmi.modalias: dmi:bvnHP:bvrP70Ver.01.18:bd03/20/2018:svnHP:pn:pvr:rvnHP:rn8270:rvrKBCVersion46.67:cvnHP:ct10:cvr: dmi.product.family: 103C_5336AN HP ZBook dmi.sys.vendor: HP To manage notifications about this
[Kernel-packages] [Bug 1798863] Re: 18.10 kernel does not appear to validate kernel module signatures correctly
apport information ** Tags added: apport-collected cosmic ** 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 ... [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 :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :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. + 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 + AudioDevicesInUse: + USERPID ACCESS COMMAND + /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 (20181017.3) + NonfreeKernelModules: nvidia_uvm nvidia + Package: linux (not installed) + ProcEnviron: + TERM=xterm-256color + PATH=(custom, no user) + XDG_RUNTIME_DIR= + LANG=en_US.UTF-8 + SHELL=/bin/bash + 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 + RelatedPackageVersions: + 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 + dmi.bios.date: 03/20/2018 + dmi.bios.vendor: HP + dmi.bios.version: P70 Ver. 01.18 + dmi.board.name: 8270 + dmi.board.vendor: HP + dmi.board.version: KBC Version 46.67 + dmi.chassis.type: 10 + dmi.chassis.vendor: HP + dmi.modalias: dmi:bvnHP:bvrP70Ver.01.18:bd03/20/2018:svnHP:pn:pvr:rvnHP:rn8270:rvrKBCVersion46.67:cvnHP:ct10:cvr: + dmi.product.family: 103C_5336AN HP ZBook + dmi.sys.vendor: HP ** Attachment added: "AlsaInfo.txt" https://bugs.launchpad.net/bugs/1798863/+attachment/5204908/+files/AlsaInfo.txt -- You received this bug notification because you are a member of Ker
[Kernel-packages] [Bug 1798863] Re: 18.10 kernel does not appear to validate kernel module signatures correctly
This could be a duplicate of bug 1798940 ** Changed in: linux (Ubuntu) Importance: Undecided => Medium ** Also affects: linux (Ubuntu Cosmic) Importance: Medium Status: Incomplete -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1798863 Title: 18.10 kernel does not appear to validate kernel module signatures correctly Status in linux package in Ubuntu: Incomplete Status in linux source package in Cosmic: Incomplete Bug description: 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 :01:00.0: enabling device (0006 -> 0007) [6.637620] nvidia :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. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1798863/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
