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/1834479 Title: depmod may prefer unsigned l-r-m nvidia modules to signed modules Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: Fix Committed Status in linux source package in Disco: Fix Released Bug description: Impact: When testing patches for bug 1834476, a bug was observed whereby modprobe was someties attempting to load the unsigned nvidia modules in /lib/modules/$(uname -r)/kernel/nvidia-N/bits rather than the signed modules from /lib/modules/$(uname -r)/kernel/nvidia-N. This appears to be because depmod is not deterministic in which module will be preferred when duplicate modules of the same name exist. Fix: The unsigned modules are no longer needed after the signed modules have been generated, so update the build script to remove the unsigned modules. Test Case: Confirm that the ko files are found in /lib/modules/$(uname -r)/kernel/nvidia-N but not in /lib/modules/$(uname -r)/kernel/nvidia-N/bits. Confirm that the modules are signed and loadable by the kernel under lockdown (or when booted with modules.sig_enforce=y), and that modprobe consistently loads the modules from the expected path after depmod. Regression Potential: The modules being removed are an intermediate build artifact and not meant to be loaded, so no regressions are expected. However, if for some reason linking the intermediate unsigned module was successful but generation of the signed module was not, the user would have been left with a module that could potentially be loaded (if not booted under UEFI secure boot) and would now be left with no modules. This is not the intended behavior and never occurred in my testing, so it's not a case we should be concerned about. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1834479/+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
