Created attachment 1552420 [details]
1. Please describe the problem:
I have secure boot enabled:
% bootctl status |head
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:
3. Did it work previously in Fedora? If so, what kernel version did the issue
*first* appear? Old kernels are available for download at
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``:
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.
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.
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.
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.
*** Bug 1698298 has been marked as a duplicate of this bug. ***
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.
Works for me also. In addition, signing with my own key works in 5.0.10
Closing as the kernel is now stable