December 2020 - openSUSE Kernel - openSUSE Mailing Lists

[opensuse-kernel] kernel lockdown and signed modules
by Giacomo Comes 18 Jan '21

18 Jan '21

Hi, I recently needed to rebuild one kmp package to add some changes. I did that and I have been using it without trouble. However, when I try to load such module on a UEFI system with secure boon enabled I get: modprobe: ERROR: could not insert '<module>': Operation not permitted and dmesg shows: Lockdown: modprobe: unsigned module loading is restricted; see man kernel_lockdown.7 After some googling I found that I need to sign the module I build myself in order to make it load on a kernel with lockdown. I followed the instructions in: https://documentation.suse.com/sbp/all/html/SBP-KMP-Manual/index.html 8.2 Signing Module Object Files (UEFI Secure Boot) I created a key and certificate (8.2.1) I signed my KMP rpm (8.2.2) using modsign-repackage I installed the rpm: <name>-kmp-<flavor> together with <name>-ueficert then I imported the certificate installed by <name>-ueficert using mokutil mokutil --import /etc/uefi/certs/<file>.crt After reboot I enrolled the new certificate. Now the command: mokutil --list-enrolled shows two certificates: the 'openSUSE Secure Boot CA' and the one I have enrolled. However when I try to load my (now signed) kernel module I still get: Lockdown: modprobe: unsigned module loading is restricted; see man kernel_lockdown.7 (but the command modsign-verify <module> gives: good signature) Am I doing something wrong? Is the documentation I'm following outdated? Is there a bug somewhere? I don't think the problem is with the UEFI bios as I get the same results on real hardware and in qemu. Any help is appreciated. Thanks. Giacomo

4 7

kernel 5.10.1: TopSeed Technology Corp. eHome Infrared Transceiver spams log with Error: urb status = -71
by Hans-Peter Jansen 20 Dec '20

20 Dec '20

Hi, using a TopSeed Technology Corp. eHome Infrared Transceiver spams kernel log with Error: urb status = -71 Details: https://bugzilla.kernel.org/show_bug.cgi?id=210801 The device is used as a receiver for the Hauppauge IR controller in a VDR setup. This issue renders this device unusable. Cheers, Pete

1 0

Looking for newer kernel
by Vinzenz Vietzke 15 Dec '20

15 Dec '20

Hi all, hopefully this is the right list for my question. Otherwise I'd appreciate a pointing in the right direction. We (TUXEDO Computers) are selling laptops and PCs with openSUSE Leap preinstalled. One problem we run into quite often is the relatively old kernel version of Leap. E.g. for our lines of AMD Renoir laptops we would need at least 5.6.x upwards to get everything running. In the past we "fixed" that by manually adding kernels from Kernel:stable which neither is a clean solution nor convenient for technically unexperienced users like many of our customers. Ubuntu has their so called "Hardware Enablement" updates via point releases which delivers newer Kernels, Mesa etc. In addition to that they maintain an so called OEM Kernel, which currently is at 5.6.x. Both things are really helpful for our purposes. So my question is: Is there something similar available for openSUSE? Maybe an intermedia kernel for Leap? Thanks vinz.

7 11

Kernel 5.10 final
by Hans-Peter Jansen 15 Dec '20

15 Dec '20

Hi Michal && Jiri, thanks for updating https://github.com/openSUSE/kernel-source/commits/stable to 5.10. Unfortunately, a last minute change broke md. https://lkml.org/lkml/2020/12/14/7 It would be nice to revert 6ffeb1c3f82 in order to not suffer from {not mountable, non booting} md setups. 5.10.1 will almost certainly also contain such a revert. Cheers, Pete

3 2

Re: Problem booting 5.10-rc7
by Michal Kubecek 14 Dec '20

14 Dec '20

On Sat, Dec 12, 2020 at 09:57:01AM +0100, Frank Krüger wrote: > Dear Michal, > > Does Kernel:Head contain the version with the three commits mentioned in > https://lkml.org/lkml/2020/12/9/722? No, these should come with 5.11-rc1, IIUC. But commit 103fbf8e4020 has been reverted in v5.10 which should also address the issue discussed in that thread. Michal

1 0

Re: nvidia-uvm and other kernel modules for the current/upcoming kernel
by Hans-Peter Jansen 10 Dec '20

10 Dec '20

Am Montag, 7. Dezember 2020, 13:32:24 CET schrieb Martin Wilck: > On Mon, 2020-12-07 at 12:18 +0000, Peter Suetterlin wrote: > > > Martin Wilck wrote: > > > > > > > > > I'm running 455.38 for my optimus laptop. Self compiled via > > > > dkms, > > > > but the uvm > > > > module builds w/o issues. > > > > > > > > > With 5.9 or higher? Without patching the kernel? > > > > > > Yes, of course. Just plain TW kernel. > > > Thanks. Just learned that Nvidia's 455 series seems to have a > workaround for the 5.9 issue. Yes, that seems to be the case, Martin. Stefan Dirsch expects a long-term release of that beast, which should be out in the next couple of days. Meanwhile, we're working an G04 fix for 5.10 (without CUDA support of course..). If all goes well, we're in a good shape for 5.10 NVIDIA-wise. The same *doesn't* hold true for drdb, Virtualbox, random external kernel module of your choice, unfortunately. Cheers, Pete

5 15