21

I am trying to modprobe wireguard as root, and it fails with:

modprobe: ERROR: could not insert 'wireguard': Operation not permitted

Adding verbose I get one more line:

[root@localhost ben]# insmod /lib/modules/5.2.11-100.fc29.x86_64/extra/wireguard.ko.xz
insmod: ERROR: could not insert module /lib/modules/5.2.11-100.fc29.x86_64/extra/wireguard.ko.xz: Operation not permitted

dkms runs fine without error. I've also disabled selinux and that made no difference. I don't see anything in the journalctl logs.

Looking through man pages and Google have not turned anything up.

I did find this helpful line in dmesg:

Lockdown: modprobe: Loading of unsigned module is restricted; see man kernel_lockdown.7

However that man page does not exist.

How can I debug this? Any pointers on where to go next?

steeldriver
  • 78,509
  • 12
  • 109
  • 152
Freedom_Ben
  • 4,284
  • 4
  • 22
  • 29

4 Answers4

17

Finally found something on it. It appears to be a "feature" where unsigned code can't be loaded into the kernel when UEFI secure boot is enabled (which it is).

To get the module loading, disable kernel lockdown via sys-rq:

# echo 1 > /proc/sys/kernel/sysrq
# echo x > /proc/sysrq-trigger

Then modprobe should work:

modprobe wireguard

For more information, see:

https://mjg59.dreamwidth.org/50577.html

https://bugzilla.redhat.com/show_bug.cgi?id=1599197

Freedom_Ben
  • 4,284
  • 4
  • 22
  • 29
  • 1
    This is a great answer, and it fixed my issue. Unfortunately, you have to do this every time you update the kernel. – user2597747 Nov 12 '19 at 18:42
  • For me this issue is still present: # modprobe -vvv wireguard modprobe: INFO: custom logging function 0x55cf4e172a20 registered insmod /lib/modules/5.3.11-300.fc31.x86_64/kernel/net/wireguard.ko.xz modprobe: INFO: Failed to insert module '/lib/modules/5.3.11-300.fc31.x86_64/kernel/net/wireguard.ko.xz': Operation not permitted modprobe: ERROR: could not insert 'wireguard': Operation not permitted modprobe: INFO: context 0x55cf4eb9b4c0 released @Freedom_Ben do you have maybe some idea why? – valentt Nov 25 '19 at 11:18
  • 1
    on ubuntu 20.04 i get permission denied for both, e.g. `bash: /proc/sys/kernel/sysrq: Permission denied` – caduceus Aug 21 '20 at 08:41
  • I'm also getting permission denied, even as sudo. I'm also using ubuntu 20 – pyramation Nov 27 '20 at 20:31
  • 1
    For anyone running into issues in the future, you can't use `sudo echo 1 > /...`. Instead, either login as root or do `echo 1 | sudo tee /path/to/file`. – Will Eccles Jan 26 '21 at 18:30
  • 4
    Unfortunately, now the trick doesn't work anymore... – Giuseppe Ricupero Mar 17 '21 at 12:27
0

My Fedora 31 distribution didn't accept echoing to sysrq.  The Arch Linux wiki suggested to use Alt+PrtSc+x (on laptops, where Fn is part of the keyboard).  The lockdown was successfully disabled and WireGuard successfully loaded.  I installed akmod, so modprobe wireguard worked for me as an alternative to SysRq+x.  (The Red Hat manual says it should be pressed on a physically attached keyboard.)

igor
  • 1
  • after rebooting: echo 1 > /proc/sys/kernel/sysrq is still required for Alt+PrtSc+x to be accepted by the system – igor Dec 29 '19 at 11:55
-1

Maybe the best for long term is to sign your modules.

For Debian and derivatives see:

https://wiki.debian.org/SecureBoot#MOK_-_Machine_Owner_Key

-1

my problem is to load os module overlay of the Centos 7.x (not compiled module), that normaly are signed... plus secure boot are not enabled (mokutil say "EFI variables are not supported on this system").

  • If you have a new question, please ask it by clicking the [Ask Question](https://unix.stackexchange.com/questions/ask) button. Include a link to this question if it helps provide context. - [From Review](/review/late-answers/416867) – G-Man Says 'Reinstate Monica' Jun 28 '22 at 16:53