Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1696671 - Kernel 5.0.5 loads unsigned kernel modules in a secureboot environment
Summary: Kernel 5.0.5 loads unsigned kernel modules in a secureboot environment
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 29
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1698298 (view as bug list)
Depends On:
Blocks: IoT
TreeView+ depends on / blocked
 
Reported: 2019-04-05 11:59 UTC by Hedayat Vatankhah
Modified: 2019-10-17 20:15 UTC (History)
22 users (show)

Fixed In Version: kernel-5.0.8-200.fc29 kernel-5.0.8-100.fc28 kernel-5.0.8-300.fc30
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-05-01 07:46:05 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)
dmsg.txt (346.56 KB, text/plain)
2019-04-05 11:59 UTC, Hedayat Vatankhah 		no flags Details
View All

Description Hedayat Vatankhah 2019-04-05 11:59:23 UTC 
Created attachment 1552420 [details]
dmsg.txt

1. Please describe the problem:
I have secure boot enabled:
% bootctl status |head
System:
     Firmware: n/a (n/a)
  Secure Boot: enabled
   Setup Mode: user

But under 5.0.5, unsigned nvidia modules get loaded:
% dmesg | grep nvidia
[   26.878524] nvidia: loading out-of-tree module taints kernel.
[   26.878531] nvidia: module license 'NVIDIA' taints kernel.
[   26.883043] nvidia: module verification failed: signature and/or required key missing - tainting kernel
[   26.891548] nvidia-nvlink: Nvlink Core is being initialized, major device number 234
[   26.891751] nvidia 0000:01:00.0: enabling device (0000 -> 0003)
[   26.891832] nvidia 0000:01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=none
[   27.598347] nvidia-uvm: Loaded the UVM driver in 8 mode, major device number 510
[   27.702455] nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms  418.56  Fri Mar 15 12:32:40 CDT 2019
[   27.787021] [drm] [nvidia-drm] [GPU ID 0x00000100] Loading driver
[   28.534534] [drm] Initialized nvidia-drm 0.0.0 20160202 for 0000:01:00.0 on minor 1


2. What is the Version-Release number of the kernel:
5.0.5-200.fc29.x86_64

3. Did it work previously in Fedora? If so, what kernel version did the issue
   *first* appear?  Old kernels are available for download at
   https://koji.fedoraproject.org/koji/packageinfo?packageID=8 :
Yes, at least it worked under 4.x.x kernels under F29. Not sure about older 5.0.x kernels


4. Can you reproduce this issue? If so, please provide the steps to reproduce
   the issue below:
I've not rebooted again, but I'd expect it'd happen always.

5. Does this problem occur with the latest Rawhide kernel? To install the
   Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by
   ``sudo dnf update --enablerepo=rawhide kernel``:
Not tried.

6. Are you running any modules that not shipped with directly Fedora's kernel?:
Yes, nvidia ones

7. Please attach the kernel logs. You can get the complete kernel log
   for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the
   issue occurred on a previous boot, use the journalctl ``-b`` flag.
Comment 1 Paul Black 2019-04-09 05:36:40 UTC 
I'm seeing the same with VirtualBox modules:
[   53.740674] vboxdrv: loading out-of-tree module taints kernel.
[   53.740799] vboxdrv: module verification failed: signature and/or required key missing - tainting kernel
[   53.747216] vboxdrv: Found 4 processor cores
[   53.763350] vboxdrv: TSC mode is Invariant, tentative frequency 3311999158 Hz
[   53.763351] vboxdrv: Successfully loaded version 6.0.4 (interface 0x00290008)
[   53.969408] VBoxNetFlt: Successfully started.
[   53.971108] VBoxNetAdp: Successfully started.
[   53.973382] VBoxPciLinuxInit
[   53.973386] vboxpci: IOMMU not found (not registered)


Also, if I sign the modules it gives an error (although they are still loaded):
[ 1410.391839] VBoxPciLinuxLinuxUnload
[ 1410.618698] PKCS#7 signature not signed with a trusted key
[ 1410.625228] vboxdrv: Found 4 processor cores
[ 1410.642357] vboxdrv: TSC mode is Invariant, tentative frequency 3311958543 Hz
[ 1410.642358] vboxdrv: Successfully loaded version 6.0.4 (interface 0x00290008)
[ 1410.872962] PKCS#7 signature not signed with a trusted key
[ 1410.874045] VBoxNetFlt: Successfully started.
[ 1410.881808] PKCS#7 signature not signed with a trusted key
[ 1410.882190] VBoxNetAdp: Successfully started.
[ 1410.890404] PKCS#7 signature not signed with a trusted key
[ 1410.890904] VBoxPciLinuxInit
[ 1410.890907] vboxpci: IOMMU not found (not registered)

The key is trusted; I still get "[    0.874853] integrity: Loaded X.509 cert 'Paul Black: 4878024124d1b99d545f7d2084a041b56657caa4'" in my output.
Comment 2 Benjamin 2019-04-12 02:29:13 UTC 
I'm having a similar issue with the VMware kernel modules. I wrote a "Hello, World" module as a test (it's attached to my report, if it helps), which confirmed that this is an issue with the kernel, not any individual module. I didn't find this bug while filing my own (https://bugzilla.redhat.com/show_bug.cgi?id=1698298), but I strongly suspect that mine is a duplicate of this one. After hearing back from someone, it can be marked as such.

I made a number of observations, though.
1. This isn't only confined to EFI secure boot, it's a kernel lockdown issue (but other parts of kernel lockdown are working as expected. Try ``sudo head /dev/mem`` and ``sudo head /dev/port``. These are blocked, as expected.). Try enabling kernel lockdown with "lockdown=1" on the kernel command line, you'll get the same results.
2. You might not be able to test with the rawhide kernel. I couldn't compile any modules on it because I couldn't find kernel-devel for it, so make failed. Perhaps someone else might know what's going on here?
3. I first noticed the issue in 5.0.3-200.fc29.x86_64, it's still in 5.0.6-200.fc29.x86_64 and it was last working for me in 4.20.16-200.fc29.x86_64.
Comment 3 Jeremy Cline 2019-04-23 14:01:44 UTC 
Hi folks, 

This should be fixed in kernel-5.0.8 builds, currently available in updates-testing. These kernels do have a different issue with module loading and signatures (https://bugzilla.redhat.com/show_bug.cgi?id=1701096, platform keys are ignored) which should be fixed in 5.10.
Comment 4 Benjamin 2019-05-01 00:48:32 UTC 
*** Bug 1698298 has been marked as a duplicate of this bug. ***
Comment 5 Benjamin 2019-05-01 01:08:55 UTC 
Can confirm that this bug and 1701096 are fixed in kernel-5.0.9-301.fc30
Sorry, I never actually tried kernel-5.0.8-200.fc29 because of 1701096

I move for this to be closed.
Comment 6 Paul Black 2019-05-01 07:34:13 UTC 
Works for me also. In addition, signing with my own key works in 5.0.10
Comment 7 Peter Robinson 2019-05-01 07:46:05 UTC 
Closing as the kernel is now stable
Note You need to log in before you can comment on or make changes to this bug.