Compatibility with secure boot?

[Wendelstein7]

I followed the instructions and it seems that I can not get lg4ff to work because I am using secure boot.

When doing sudo make load I get modprobe: ERROR: could not insert 'hid_logitech_new': Operation not permitted. When Googling around for this error message various pages suggested turning off secure boot. I do not want to disable secure boot.

Is there anything else I can do to get the software to work, without disabling secure boot?

Here's the full install log:

user@machine:~/Documents/new-lg4ff$ make
make -C /lib/modules/`uname -r`/build M=$PWD
make[1]: Entering directory '/usr/src/linux-headers-5.15.0-27-generic'
make[1]: Leaving directory '/usr/src/linux-headers-5.15.0-27-generic'
user@machine:~/Documents/new-lg4ff$ sudo make install
make -C /lib/modules/`uname -r`/build M=$PWD
make[1]: Entering directory '/usr/src/linux-headers-5.15.0-27-generic'
make[1]: Leaving directory '/usr/src/linux-headers-5.15.0-27-generic'
make -C /lib/modules/`uname -r`/build M=$PWD modules_install
make[1]: Entering directory '/usr/src/linux-headers-5.15.0-27-generic'
arch/x86/Makefile:142: CONFIG_X86_X32 enabled but no binutils support
  INSTALL /lib/modules/5.15.0-27-generic/extra/hid-logitech-new.ko
  SIGN    /lib/modules/5.15.0-27-generic/extra/hid-logitech-new.ko
At main.c:160:
- SSL error:FFFFFFFF80000002:system library::No such file or directory: ../crypto/bio/bss_file.c:67
- SSL error:10000080:BIO routines::no such file: ../crypto/bio/bss_file.c:75
sign-file: certs/signing_key.pem: No such file or directory
  DEPMOD  /lib/modules/5.15.0-27-generic
Warning: modules_install: missing 'System.map' file. Skipping depmod.
make[1]: Leaving directory '/usr/src/linux-headers-5.15.0-27-generic'
depmod -A
user@machine:~/Documents/new-lg4ff$ sudo make load
make -C /lib/modules/`uname -r`/build M=$PWD
make[1]: Entering directory '/usr/src/linux-headers-5.15.0-27-generic'
make[1]: Leaving directory '/usr/src/linux-headers-5.15.0-27-generic'
make -C /lib/modules/`uname -r`/build M=$PWD modules_install
make[1]: Entering directory '/usr/src/linux-headers-5.15.0-27-generic'
arch/x86/Makefile:142: CONFIG_X86_X32 enabled but no binutils support
  INSTALL /lib/modules/5.15.0-27-generic/extra/hid-logitech-new.ko
  SIGN    /lib/modules/5.15.0-27-generic/extra/hid-logitech-new.ko
At main.c:160:
- SSL error:FFFFFFFF80000002:system library::No such file or directory: ../crypto/bio/bss_file.c:67
- SSL error:10000080:BIO routines::no such file: ../crypto/bio/bss_file.c:75
sign-file: certs/signing_key.pem: No such file or directory
  DEPMOD  /lib/modules/5.15.0-27-generic
Warning: modules_install: missing 'System.map' file. Skipping depmod.
make[1]: Leaving directory '/usr/src/linux-headers-5.15.0-27-generic'
depmod -A
rmmod hid-logitech 2> /dev/null || true
rmmod hid-logitech-new 2> /dev/null || true
modprobe hid-logitech-new 
modprobe: ERROR: could not insert 'hid_logitech_new': Operation not permitted
make: *** [Makefile:16: load] Error 1
user@machine:~/Documents/new-lg4ff$

Thanks for reading, I am looking forward to your answers and knowledge!

[berarma]

I haven't used Secure Boot myself and have no knowledge, sorry. Anyway, the selected answer here sounds promising: https://askubuntu.com/questions/1114867/operation-not-permitted-when-trying-to-modprobe-xpad

It seems signing the module could be enough.

[rockerbacon]

Secure boot is just doing its job in this instance: keeping the system from starting in case any module the OS developers do not know about shows up. This is one of the ways secure boot keeps your system secure, if any existing module is tampered with or any unexpected module shows up, the device will refuse to boot.

It works by checking signatures stored within the boot files against keys stored in the device's firmware (motherboard). Distributions which are secure boot compatible (not that many) will work with the necessary companies to ensure the signatures in their files can be validated using the keys shipped with most consumer devices.

Most motherboards will not be locked to their original secure boot keys and allow the user to load custom information at the firmware configuration menu (BIOS) or through UEFI APIs. This is how one would work on this, creating custom secure boot keys, loading them into the motherboard and signing their own files with these custom keys. Here's a detailed video on this process for the Fedora 35 distribution: https://www.youtube.com/watch?v=cR9chz06DDk

Note that this process may vary slightly for each distribution and it's possible it will need to be done again after kernel updates.

The optimal solution for this would be #35. If this module is in the upstream, everything will just work as distributions will sign new-lg4ff along with everything else.