User reports a kernel taint message following updating to kernel 5.5.5. Has anything changed in kernel 5.5 that explains this?
This is the message they're seeing: https://ask.fedoraproject.org/t/kernel-tainted-after-running-updates/5487/4?...
My understanding of these messages is: 1. the proprietary nvidia driver is being loaded and used 2. since the module is not signed, the kernel is tainted
But I'm not sure what else I can infer about kernel taint. Are all the other lockdowns still in place? Ideally the user would register a key using mokutil, and sign the module. But if they don't do that, they are still better off than if they disable UEFI Secure Boot to avoid getting the kernel taint message, correct?
Thanks,
On Wed, Feb 26, 2020 at 5:03 PM Chris Murphy lists@colorremedies.com wrote:
User reports a kernel taint message following updating to kernel 5.5.5. Has anything changed in kernel 5.5 that explains this?
This is the message they're seeing:
https://ask.fedoraproject.org/t/kernel-tainted-after-running-updates/5487/4?...
No, nothing has changed here, loading a proprietary module has marked the kernel as tainted for a very long time. If you went back to 2.6 kernels, you would see a similar message about the kernel being tainted. The message has expanded a bit over the years as we check for things like module signatures, etc, but the end result is the same the taint flag is P for proprietary module.
https://www.kernel.org/doc/html/latest/admin-guide/tainted-kernels.html
My understanding of these messages is:
- the proprietary nvidia driver is being loaded and used
- since the module is not signed, the kernel is tainted
Actually, the kernel would be tainted with the same flag whether the module was signed or not.
But I'm not sure what else I can infer about kernel taint. Are all the other lockdowns still in place? Ideally the user would register a key using mokutil, and sign the module. But if they don't do that, they are still better off than if they disable UEFI Secure Boot to avoid getting the kernel taint message, correct?
Unless the user has gone to the trouble of self signing a proprietary
module, and adding that key to the keyring, UEFI secure boot had to be disabled to even load the module. Module signatures are used and checked outside of secure boot as well. Still, even if they do sign the module and add that key to enable the module to work with secure boot, the kernel will be tainted P.
Justin
On Thu, Feb 27, 2020 at 5:54 AM Justin Forbes jforbes@redhat.com wrote:
No, nothing has changed here, loading a proprietary module has marked the kernel as tainted for a very long time. If you went back to 2.6 kernels, you would see a similar message about the kernel being tainted. The message has expanded a bit over the years as we check for things like module signatures, etc, but the end result is the same the taint flag is P for proprietary module.
Gotcha.
Unless the user has gone to the trouble of self signing a proprietary module, and adding that key to the keyring, UEFI secure boot had to be disabled to even load the module. Module signatures are used and checked outside of secure boot as well. Still, even if they do sign the module and add that key to enable the module to work with secure boot, the kernel will be tainted P.
Is it technically possible for the Fedora signing key to be used to sign a 3rd party key, thereby allowing the loading of 3rd party modules signed with that 3rd party key?
Policy wise, is it likely that could be done? e.g. trusting the RPM Fusion Nvidia and Broadcom kernel modules?
On the one hand Fedora is supporting UEFI Secure Boot out of the box, ostensibly we want users to leave it enabled. But because self-signing modules is tedious, possibly quite a lot of users are just disabling UEFI Secure Boot. I'm not sure if it's possible to make this work out of the box for users, but it would be nice to not just make it a documentation problem.
On Tue, Mar 17, 2020 at 1:11 PM Chris Murphy lists@colorremedies.com wrote:
On Thu, Feb 27, 2020 at 5:54 AM Justin Forbes jforbes@redhat.com wrote:
No, nothing has changed here, loading a proprietary module has marked
the kernel as tainted for a very long time. If you went back to 2.6 kernels, you would see a similar message about the kernel being tainted. The message has expanded a bit over the years as we check for things like module signatures, etc, but the end result is the same the taint flag is P for proprietary module.
Gotcha.
Unless the user has gone to the trouble of self signing a proprietary
module, and adding that key to the keyring, UEFI secure boot had to be disabled to even load the module. Module signatures are used and checked outside of secure boot as well. Still, even if they do sign the module and add that key to enable the module to work with secure boot, the kernel will be tainted P.
Is it technically possible for the Fedora signing key to be used to sign a 3rd party key, thereby allowing the loading of 3rd party modules signed with that 3rd party key?
Policy wise, is it likely that could be done? e.g. trusting the RPM Fusion Nvidia and Broadcom kernel modules?
This is something that will *not* be done or considered. If those third
party repositories wanted to, they could set up their own key and signing process, and simply ask the users to import their key with detailed instructions, but it has to be a conscious effort on the part of the user to extend that trust.
On the one hand Fedora is supporting UEFI Secure Boot out of the box,
ostensibly we want users to leave it enabled. But because self-signing modules is tedious, possibly quite a lot of users are just disabling UEFI Secure Boot. I'm not sure if it's possible to make this work out of the box for users, but it would be nice to not just make it a documentation problem.
The act of generating the key and getting it into the key ring is a bit tedious, but this is something that you only need to do once. It should be tedious, it is not a step to be taken lightly. The act of self signing a module with that key is not difficult at all. It can certainly be automated if you feel comfortable with the level of security that such automation would provide.
kernel@lists.fedoraproject.org
-
Chris Murphy -
Florian Weimer -
Justin Forbes