Why do I get “Required key not available” when install 3rd party kernel modules or after a kernel...
This issue happens only on UEFI systems with enabled Secure Boot.
When I try to install DKMS modules like VirtualBox, Nvidia, or Broadcom drivers, they do not install and I get Required key not available
when I try to modprobe
them.
VirtualBox complains that vboxdrv
is not loaded.
Broadcom wl
driver is shown in lspci -k
as a kernel module but is not in use. sudo modprobe wl
throws Required key not available
.
Also this issue may happen when I install some kernel modules from git sources.
This issue may appear after a kernel update as disabled wireless adapter, black screen after a reboot, etc.
How can I fix it?
kernel uefi secure-boot dkms
add a comment |
This issue happens only on UEFI systems with enabled Secure Boot.
When I try to install DKMS modules like VirtualBox, Nvidia, or Broadcom drivers, they do not install and I get Required key not available
when I try to modprobe
them.
VirtualBox complains that vboxdrv
is not loaded.
Broadcom wl
driver is shown in lspci -k
as a kernel module but is not in use. sudo modprobe wl
throws Required key not available
.
Also this issue may happen when I install some kernel modules from git sources.
This issue may appear after a kernel update as disabled wireless adapter, black screen after a reboot, etc.
How can I fix it?
kernel uefi secure-boot dkms
Similar: askubuntu.com/questions/760671/…
– Tor Klingberg
Feb 26 '18 at 10:50
add a comment |
This issue happens only on UEFI systems with enabled Secure Boot.
When I try to install DKMS modules like VirtualBox, Nvidia, or Broadcom drivers, they do not install and I get Required key not available
when I try to modprobe
them.
VirtualBox complains that vboxdrv
is not loaded.
Broadcom wl
driver is shown in lspci -k
as a kernel module but is not in use. sudo modprobe wl
throws Required key not available
.
Also this issue may happen when I install some kernel modules from git sources.
This issue may appear after a kernel update as disabled wireless adapter, black screen after a reboot, etc.
How can I fix it?
kernel uefi secure-boot dkms
This issue happens only on UEFI systems with enabled Secure Boot.
When I try to install DKMS modules like VirtualBox, Nvidia, or Broadcom drivers, they do not install and I get Required key not available
when I try to modprobe
them.
VirtualBox complains that vboxdrv
is not loaded.
Broadcom wl
driver is shown in lspci -k
as a kernel module but is not in use. sudo modprobe wl
throws Required key not available
.
Also this issue may happen when I install some kernel modules from git sources.
This issue may appear after a kernel update as disabled wireless adapter, black screen after a reboot, etc.
How can I fix it?
kernel uefi secure-boot dkms
kernel uefi secure-boot dkms
edited Feb 19 '17 at 18:36
Pilot6
asked Apr 25 '16 at 7:48
Pilot6Pilot6
51.7k15107197
51.7k15107197
Similar: askubuntu.com/questions/760671/…
– Tor Klingberg
Feb 26 '18 at 10:50
add a comment |
Similar: askubuntu.com/questions/760671/…
– Tor Klingberg
Feb 26 '18 at 10:50
Similar: askubuntu.com/questions/760671/…
– Tor Klingberg
Feb 26 '18 at 10:50
Similar: askubuntu.com/questions/760671/…
– Tor Klingberg
Feb 26 '18 at 10:50
add a comment |
4 Answers
4
active
oldest
votes
Since Ubuntu kernel 4.4.0-20 the EFI_SECURE_BOOT_SIG_ENFORCE
kernel config has been enabled. That prevents from loading unsigned third party modules if UEFI Secure Boot is enabled.
The easiest way to fix this issue is to disable Secure Boot in UEFI (BIOS) settings.
In most cases you can get into UEFI settings using grub menu. Press ESC button on booting, get into grub menu and select System Setup. Secure Boot option should be in "Security" or "Boot" section of the UEFI.
You can get into UEFI directly, but it depends on your hardware. Read your computer manual to see how to get there. It may be Del, or F2 on boot, or something else.
An alternative way is to disable Secure Boot using mokutil
.
Since Ubuntu kernel build 4.4.0-21.37 this can be fixed by running
sudo apt install mokutil
sudo mokutil --disable-validation
It will require to create a password. The password should be at least 8 characters long. After you reboot, UEFI will ask if you want to change security settings. Choose "Yes".
Then you will be asked to enter the previously created password. Some UEFI firmware asks not for the full password, but to enter some characters of it, like 1st, 3rd, etc. Be careful. Some people do not understand this. I did not get it from the first attempt either ;-)
Update: Now this kernel config is enabled in all supported Ubuntu kernels. Ubuntu 16.04, 15.10 and 14.04 are affected.
This doesn't work for me. @Sputnik answer does. But still, I'd like to know why mokutil is asking me for a password and when do I need it?
– Alwin Kesler
Apr 28 '16 at 19:49
6
@AlwinKesler It asks for a password which it will validate after reboot, before the changes to the MOK database are actually carried out. Without this, a rogue process could change keys in the MOK database which become effective after the next reboot. Also, now the platform 'knows' that the person requesting the change is the same person who is physically present after the reboot, and will thus have passed hardware security measures, such as having physical access to the machine and knowing the boot time system password.
– zwets
May 9 '16 at 8:44
@Pilot6: I am still on Ubuntu 14.04 LTS due to some technical issues. Thanks a lot for updating the answer.
– Ravi Joshi
Jul 22 '16 at 15:37
mokutil did not work for me on a Toshiba laptop in 16.04. It ran just fine, but upon startup the secure boot was still there. I ended up using the first option, pressing escape upon boot and turning off secure boot.
– kingledion
Feb 8 '17 at 3:49
2
Worked for me on Ubuntu 18.04. Couldn't figure out for the life of me why installing nvidia drivers wasn't working via any means, or even by reverting to 16.04. Gah! This fixed it. So much time wasted.
– Nate
Jul 12 '18 at 5:09
|
show 2 more comments
As suggested by user @zwets, I'm copying (with edits) an answer here:
Since kernel version 4.4.0-20, it was enforced that unsigned kernel modules will not be allowed to run with Secure Boot enabled. If you'd want to keep Secure Boot and also run these modules, then the next logical step is to sign those modules.
So let's try it.
Create signing keys
openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -nodes -days 36500 -subj "/CN=Descriptive name/"
Sign the module
sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 ./MOK.priv ./MOK.der /path/to/module
Register the keys to Secure Boot
sudo mokutil --import MOK.der
Supply a password for later use after reboot
Reboot
and follow instructions to Enroll MOK (Machine Owner Key). Here's a sample with pictures. The system will reboot one more time.
Please let me know if your modules would run this way on Ubuntu 16.04 (on kernel 4.4.0-21, I believe).
Resources: Detailed website article for Fedora and Ubuntu implementation of module signing. (they've been working on it) ;-)
Additional note for the security (extra-)conscious: ;-)
Since the private key you created (MOK.priv
in this example) can be used by anyone who can have access to it, it is good practice to keep it secure. You may chmod
it, encrypt (gpg
) it, or store it somewhere else safe(r). Or, as noted in this comment, remove the option -nodes
in step number 1. This will encrypt the key with a passphrase.
On Ubuntu 14.10 I continued to see 'required key not available' trying to install a broadcom driver compiled from source, despite preregistering the key and signing the driver. Disabling validation worked.
– Mark
Jul 16 '16 at 0:37
1
This worked for me for VirtualBox and Ubuntu 16.04.
– YtvwlD
Aug 4 '16 at 11:18
1
I get the following error in step 3: "EFI variables are not supported on this system". "dmesg" has no efi entries ("dmesg | grep efi" has no results) What else can I do? Thanks
– musbach
Jan 7 '17 at 15:55
You can substitute the path in with $(modinfo -n modulename)
– Shane
Aug 7 '17 at 1:56
add a comment |
You can disable Secure Boot (UEFI) in the BIOS with the following steps:
Reboot your machine and enter the BIOS Menu (In my case pressing F2)
Search for Secure Boot and change to Legacy
In an ASUS motherboard:
- Go to the Advanced Mode (F7)
- Go in the Secure Boot option under the Boot section
- Change "Windows UEFI mode" with "Other OS"
- Save and restart to apply settings (F10)
2
Secure Boot and "Legacy" are different settings.
– Pilot6
Aug 12 '16 at 10:53
But if you have "legacy boot" enabled instead of UEFI, does that entail that Secure Boot is not enabled?
– Supernormal
Jan 9 '17 at 15:26
@Supernormal, yes, this is what I understand.
– Sputnik
Nov 17 '17 at 11:22
add a comment |
You can also Disable Secure Boot in shim-signed running sudo update-secureboot-policy
. This wiki page explains this method:
- Open a terminal (Ctrl + Alt + T), and execute sudo update-secureboot-policy and then select Yes.
- Enter a temporary password between 8 to 16 digits. (For example, 12345678, we will use this password later
- Enter the same password again to confirm.
- Reboot the system and press any key when you see the blue screen (MOK management
- Select Change Secure Boot state
- Enter the password you had selected in Step 2 and press Enter.
- Select Yes to disable Secure Boot in shim-signed.
- Press Enter key to finish the whole procedure.
You can still enable Secure Boot in shim-signed again. Just execute
sudo update-secureboot-policy --enable
and then follow the steps above
add a comment |
protected by Pilot6 Aug 26 '17 at 16:14
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
Since Ubuntu kernel 4.4.0-20 the EFI_SECURE_BOOT_SIG_ENFORCE
kernel config has been enabled. That prevents from loading unsigned third party modules if UEFI Secure Boot is enabled.
The easiest way to fix this issue is to disable Secure Boot in UEFI (BIOS) settings.
In most cases you can get into UEFI settings using grub menu. Press ESC button on booting, get into grub menu and select System Setup. Secure Boot option should be in "Security" or "Boot" section of the UEFI.
You can get into UEFI directly, but it depends on your hardware. Read your computer manual to see how to get there. It may be Del, or F2 on boot, or something else.
An alternative way is to disable Secure Boot using mokutil
.
Since Ubuntu kernel build 4.4.0-21.37 this can be fixed by running
sudo apt install mokutil
sudo mokutil --disable-validation
It will require to create a password. The password should be at least 8 characters long. After you reboot, UEFI will ask if you want to change security settings. Choose "Yes".
Then you will be asked to enter the previously created password. Some UEFI firmware asks not for the full password, but to enter some characters of it, like 1st, 3rd, etc. Be careful. Some people do not understand this. I did not get it from the first attempt either ;-)
Update: Now this kernel config is enabled in all supported Ubuntu kernels. Ubuntu 16.04, 15.10 and 14.04 are affected.
This doesn't work for me. @Sputnik answer does. But still, I'd like to know why mokutil is asking me for a password and when do I need it?
– Alwin Kesler
Apr 28 '16 at 19:49
6
@AlwinKesler It asks for a password which it will validate after reboot, before the changes to the MOK database are actually carried out. Without this, a rogue process could change keys in the MOK database which become effective after the next reboot. Also, now the platform 'knows' that the person requesting the change is the same person who is physically present after the reboot, and will thus have passed hardware security measures, such as having physical access to the machine and knowing the boot time system password.
– zwets
May 9 '16 at 8:44
@Pilot6: I am still on Ubuntu 14.04 LTS due to some technical issues. Thanks a lot for updating the answer.
– Ravi Joshi
Jul 22 '16 at 15:37
mokutil did not work for me on a Toshiba laptop in 16.04. It ran just fine, but upon startup the secure boot was still there. I ended up using the first option, pressing escape upon boot and turning off secure boot.
– kingledion
Feb 8 '17 at 3:49
2
Worked for me on Ubuntu 18.04. Couldn't figure out for the life of me why installing nvidia drivers wasn't working via any means, or even by reverting to 16.04. Gah! This fixed it. So much time wasted.
– Nate
Jul 12 '18 at 5:09
|
show 2 more comments
Since Ubuntu kernel 4.4.0-20 the EFI_SECURE_BOOT_SIG_ENFORCE
kernel config has been enabled. That prevents from loading unsigned third party modules if UEFI Secure Boot is enabled.
The easiest way to fix this issue is to disable Secure Boot in UEFI (BIOS) settings.
In most cases you can get into UEFI settings using grub menu. Press ESC button on booting, get into grub menu and select System Setup. Secure Boot option should be in "Security" or "Boot" section of the UEFI.
You can get into UEFI directly, but it depends on your hardware. Read your computer manual to see how to get there. It may be Del, or F2 on boot, or something else.
An alternative way is to disable Secure Boot using mokutil
.
Since Ubuntu kernel build 4.4.0-21.37 this can be fixed by running
sudo apt install mokutil
sudo mokutil --disable-validation
It will require to create a password. The password should be at least 8 characters long. After you reboot, UEFI will ask if you want to change security settings. Choose "Yes".
Then you will be asked to enter the previously created password. Some UEFI firmware asks not for the full password, but to enter some characters of it, like 1st, 3rd, etc. Be careful. Some people do not understand this. I did not get it from the first attempt either ;-)
Update: Now this kernel config is enabled in all supported Ubuntu kernels. Ubuntu 16.04, 15.10 and 14.04 are affected.
This doesn't work for me. @Sputnik answer does. But still, I'd like to know why mokutil is asking me for a password and when do I need it?
– Alwin Kesler
Apr 28 '16 at 19:49
6
@AlwinKesler It asks for a password which it will validate after reboot, before the changes to the MOK database are actually carried out. Without this, a rogue process could change keys in the MOK database which become effective after the next reboot. Also, now the platform 'knows' that the person requesting the change is the same person who is physically present after the reboot, and will thus have passed hardware security measures, such as having physical access to the machine and knowing the boot time system password.
– zwets
May 9 '16 at 8:44
@Pilot6: I am still on Ubuntu 14.04 LTS due to some technical issues. Thanks a lot for updating the answer.
– Ravi Joshi
Jul 22 '16 at 15:37
mokutil did not work for me on a Toshiba laptop in 16.04. It ran just fine, but upon startup the secure boot was still there. I ended up using the first option, pressing escape upon boot and turning off secure boot.
– kingledion
Feb 8 '17 at 3:49
2
Worked for me on Ubuntu 18.04. Couldn't figure out for the life of me why installing nvidia drivers wasn't working via any means, or even by reverting to 16.04. Gah! This fixed it. So much time wasted.
– Nate
Jul 12 '18 at 5:09
|
show 2 more comments
Since Ubuntu kernel 4.4.0-20 the EFI_SECURE_BOOT_SIG_ENFORCE
kernel config has been enabled. That prevents from loading unsigned third party modules if UEFI Secure Boot is enabled.
The easiest way to fix this issue is to disable Secure Boot in UEFI (BIOS) settings.
In most cases you can get into UEFI settings using grub menu. Press ESC button on booting, get into grub menu and select System Setup. Secure Boot option should be in "Security" or "Boot" section of the UEFI.
You can get into UEFI directly, but it depends on your hardware. Read your computer manual to see how to get there. It may be Del, or F2 on boot, or something else.
An alternative way is to disable Secure Boot using mokutil
.
Since Ubuntu kernel build 4.4.0-21.37 this can be fixed by running
sudo apt install mokutil
sudo mokutil --disable-validation
It will require to create a password. The password should be at least 8 characters long. After you reboot, UEFI will ask if you want to change security settings. Choose "Yes".
Then you will be asked to enter the previously created password. Some UEFI firmware asks not for the full password, but to enter some characters of it, like 1st, 3rd, etc. Be careful. Some people do not understand this. I did not get it from the first attempt either ;-)
Update: Now this kernel config is enabled in all supported Ubuntu kernels. Ubuntu 16.04, 15.10 and 14.04 are affected.
Since Ubuntu kernel 4.4.0-20 the EFI_SECURE_BOOT_SIG_ENFORCE
kernel config has been enabled. That prevents from loading unsigned third party modules if UEFI Secure Boot is enabled.
The easiest way to fix this issue is to disable Secure Boot in UEFI (BIOS) settings.
In most cases you can get into UEFI settings using grub menu. Press ESC button on booting, get into grub menu and select System Setup. Secure Boot option should be in "Security" or "Boot" section of the UEFI.
You can get into UEFI directly, but it depends on your hardware. Read your computer manual to see how to get there. It may be Del, or F2 on boot, or something else.
An alternative way is to disable Secure Boot using mokutil
.
Since Ubuntu kernel build 4.4.0-21.37 this can be fixed by running
sudo apt install mokutil
sudo mokutil --disable-validation
It will require to create a password. The password should be at least 8 characters long. After you reboot, UEFI will ask if you want to change security settings. Choose "Yes".
Then you will be asked to enter the previously created password. Some UEFI firmware asks not for the full password, but to enter some characters of it, like 1st, 3rd, etc. Be careful. Some people do not understand this. I did not get it from the first attempt either ;-)
Update: Now this kernel config is enabled in all supported Ubuntu kernels. Ubuntu 16.04, 15.10 and 14.04 are affected.
edited Aug 14 '16 at 10:32
answered Apr 25 '16 at 7:51
Pilot6Pilot6
51.7k15107197
51.7k15107197
This doesn't work for me. @Sputnik answer does. But still, I'd like to know why mokutil is asking me for a password and when do I need it?
– Alwin Kesler
Apr 28 '16 at 19:49
6
@AlwinKesler It asks for a password which it will validate after reboot, before the changes to the MOK database are actually carried out. Without this, a rogue process could change keys in the MOK database which become effective after the next reboot. Also, now the platform 'knows' that the person requesting the change is the same person who is physically present after the reboot, and will thus have passed hardware security measures, such as having physical access to the machine and knowing the boot time system password.
– zwets
May 9 '16 at 8:44
@Pilot6: I am still on Ubuntu 14.04 LTS due to some technical issues. Thanks a lot for updating the answer.
– Ravi Joshi
Jul 22 '16 at 15:37
mokutil did not work for me on a Toshiba laptop in 16.04. It ran just fine, but upon startup the secure boot was still there. I ended up using the first option, pressing escape upon boot and turning off secure boot.
– kingledion
Feb 8 '17 at 3:49
2
Worked for me on Ubuntu 18.04. Couldn't figure out for the life of me why installing nvidia drivers wasn't working via any means, or even by reverting to 16.04. Gah! This fixed it. So much time wasted.
– Nate
Jul 12 '18 at 5:09
|
show 2 more comments
This doesn't work for me. @Sputnik answer does. But still, I'd like to know why mokutil is asking me for a password and when do I need it?
– Alwin Kesler
Apr 28 '16 at 19:49
6
@AlwinKesler It asks for a password which it will validate after reboot, before the changes to the MOK database are actually carried out. Without this, a rogue process could change keys in the MOK database which become effective after the next reboot. Also, now the platform 'knows' that the person requesting the change is the same person who is physically present after the reboot, and will thus have passed hardware security measures, such as having physical access to the machine and knowing the boot time system password.
– zwets
May 9 '16 at 8:44
@Pilot6: I am still on Ubuntu 14.04 LTS due to some technical issues. Thanks a lot for updating the answer.
– Ravi Joshi
Jul 22 '16 at 15:37
mokutil did not work for me on a Toshiba laptop in 16.04. It ran just fine, but upon startup the secure boot was still there. I ended up using the first option, pressing escape upon boot and turning off secure boot.
– kingledion
Feb 8 '17 at 3:49
2
Worked for me on Ubuntu 18.04. Couldn't figure out for the life of me why installing nvidia drivers wasn't working via any means, or even by reverting to 16.04. Gah! This fixed it. So much time wasted.
– Nate
Jul 12 '18 at 5:09
This doesn't work for me. @Sputnik answer does. But still, I'd like to know why mokutil is asking me for a password and when do I need it?
– Alwin Kesler
Apr 28 '16 at 19:49
This doesn't work for me. @Sputnik answer does. But still, I'd like to know why mokutil is asking me for a password and when do I need it?
– Alwin Kesler
Apr 28 '16 at 19:49
6
6
@AlwinKesler It asks for a password which it will validate after reboot, before the changes to the MOK database are actually carried out. Without this, a rogue process could change keys in the MOK database which become effective after the next reboot. Also, now the platform 'knows' that the person requesting the change is the same person who is physically present after the reboot, and will thus have passed hardware security measures, such as having physical access to the machine and knowing the boot time system password.
– zwets
May 9 '16 at 8:44
@AlwinKesler It asks for a password which it will validate after reboot, before the changes to the MOK database are actually carried out. Without this, a rogue process could change keys in the MOK database which become effective after the next reboot. Also, now the platform 'knows' that the person requesting the change is the same person who is physically present after the reboot, and will thus have passed hardware security measures, such as having physical access to the machine and knowing the boot time system password.
– zwets
May 9 '16 at 8:44
@Pilot6: I am still on Ubuntu 14.04 LTS due to some technical issues. Thanks a lot for updating the answer.
– Ravi Joshi
Jul 22 '16 at 15:37
@Pilot6: I am still on Ubuntu 14.04 LTS due to some technical issues. Thanks a lot for updating the answer.
– Ravi Joshi
Jul 22 '16 at 15:37
mokutil did not work for me on a Toshiba laptop in 16.04. It ran just fine, but upon startup the secure boot was still there. I ended up using the first option, pressing escape upon boot and turning off secure boot.
– kingledion
Feb 8 '17 at 3:49
mokutil did not work for me on a Toshiba laptop in 16.04. It ran just fine, but upon startup the secure boot was still there. I ended up using the first option, pressing escape upon boot and turning off secure boot.
– kingledion
Feb 8 '17 at 3:49
2
2
Worked for me on Ubuntu 18.04. Couldn't figure out for the life of me why installing nvidia drivers wasn't working via any means, or even by reverting to 16.04. Gah! This fixed it. So much time wasted.
– Nate
Jul 12 '18 at 5:09
Worked for me on Ubuntu 18.04. Couldn't figure out for the life of me why installing nvidia drivers wasn't working via any means, or even by reverting to 16.04. Gah! This fixed it. So much time wasted.
– Nate
Jul 12 '18 at 5:09
|
show 2 more comments
As suggested by user @zwets, I'm copying (with edits) an answer here:
Since kernel version 4.4.0-20, it was enforced that unsigned kernel modules will not be allowed to run with Secure Boot enabled. If you'd want to keep Secure Boot and also run these modules, then the next logical step is to sign those modules.
So let's try it.
Create signing keys
openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -nodes -days 36500 -subj "/CN=Descriptive name/"
Sign the module
sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 ./MOK.priv ./MOK.der /path/to/module
Register the keys to Secure Boot
sudo mokutil --import MOK.der
Supply a password for later use after reboot
Reboot
and follow instructions to Enroll MOK (Machine Owner Key). Here's a sample with pictures. The system will reboot one more time.
Please let me know if your modules would run this way on Ubuntu 16.04 (on kernel 4.4.0-21, I believe).
Resources: Detailed website article for Fedora and Ubuntu implementation of module signing. (they've been working on it) ;-)
Additional note for the security (extra-)conscious: ;-)
Since the private key you created (MOK.priv
in this example) can be used by anyone who can have access to it, it is good practice to keep it secure. You may chmod
it, encrypt (gpg
) it, or store it somewhere else safe(r). Or, as noted in this comment, remove the option -nodes
in step number 1. This will encrypt the key with a passphrase.
On Ubuntu 14.10 I continued to see 'required key not available' trying to install a broadcom driver compiled from source, despite preregistering the key and signing the driver. Disabling validation worked.
– Mark
Jul 16 '16 at 0:37
1
This worked for me for VirtualBox and Ubuntu 16.04.
– YtvwlD
Aug 4 '16 at 11:18
1
I get the following error in step 3: "EFI variables are not supported on this system". "dmesg" has no efi entries ("dmesg | grep efi" has no results) What else can I do? Thanks
– musbach
Jan 7 '17 at 15:55
You can substitute the path in with $(modinfo -n modulename)
– Shane
Aug 7 '17 at 1:56
add a comment |
As suggested by user @zwets, I'm copying (with edits) an answer here:
Since kernel version 4.4.0-20, it was enforced that unsigned kernel modules will not be allowed to run with Secure Boot enabled. If you'd want to keep Secure Boot and also run these modules, then the next logical step is to sign those modules.
So let's try it.
Create signing keys
openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -nodes -days 36500 -subj "/CN=Descriptive name/"
Sign the module
sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 ./MOK.priv ./MOK.der /path/to/module
Register the keys to Secure Boot
sudo mokutil --import MOK.der
Supply a password for later use after reboot
Reboot
and follow instructions to Enroll MOK (Machine Owner Key). Here's a sample with pictures. The system will reboot one more time.
Please let me know if your modules would run this way on Ubuntu 16.04 (on kernel 4.4.0-21, I believe).
Resources: Detailed website article for Fedora and Ubuntu implementation of module signing. (they've been working on it) ;-)
Additional note for the security (extra-)conscious: ;-)
Since the private key you created (MOK.priv
in this example) can be used by anyone who can have access to it, it is good practice to keep it secure. You may chmod
it, encrypt (gpg
) it, or store it somewhere else safe(r). Or, as noted in this comment, remove the option -nodes
in step number 1. This will encrypt the key with a passphrase.
On Ubuntu 14.10 I continued to see 'required key not available' trying to install a broadcom driver compiled from source, despite preregistering the key and signing the driver. Disabling validation worked.
– Mark
Jul 16 '16 at 0:37
1
This worked for me for VirtualBox and Ubuntu 16.04.
– YtvwlD
Aug 4 '16 at 11:18
1
I get the following error in step 3: "EFI variables are not supported on this system". "dmesg" has no efi entries ("dmesg | grep efi" has no results) What else can I do? Thanks
– musbach
Jan 7 '17 at 15:55
You can substitute the path in with $(modinfo -n modulename)
– Shane
Aug 7 '17 at 1:56
add a comment |
As suggested by user @zwets, I'm copying (with edits) an answer here:
Since kernel version 4.4.0-20, it was enforced that unsigned kernel modules will not be allowed to run with Secure Boot enabled. If you'd want to keep Secure Boot and also run these modules, then the next logical step is to sign those modules.
So let's try it.
Create signing keys
openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -nodes -days 36500 -subj "/CN=Descriptive name/"
Sign the module
sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 ./MOK.priv ./MOK.der /path/to/module
Register the keys to Secure Boot
sudo mokutil --import MOK.der
Supply a password for later use after reboot
Reboot
and follow instructions to Enroll MOK (Machine Owner Key). Here's a sample with pictures. The system will reboot one more time.
Please let me know if your modules would run this way on Ubuntu 16.04 (on kernel 4.4.0-21, I believe).
Resources: Detailed website article for Fedora and Ubuntu implementation of module signing. (they've been working on it) ;-)
Additional note for the security (extra-)conscious: ;-)
Since the private key you created (MOK.priv
in this example) can be used by anyone who can have access to it, it is good practice to keep it secure. You may chmod
it, encrypt (gpg
) it, or store it somewhere else safe(r). Or, as noted in this comment, remove the option -nodes
in step number 1. This will encrypt the key with a passphrase.
As suggested by user @zwets, I'm copying (with edits) an answer here:
Since kernel version 4.4.0-20, it was enforced that unsigned kernel modules will not be allowed to run with Secure Boot enabled. If you'd want to keep Secure Boot and also run these modules, then the next logical step is to sign those modules.
So let's try it.
Create signing keys
openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -nodes -days 36500 -subj "/CN=Descriptive name/"
Sign the module
sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 ./MOK.priv ./MOK.der /path/to/module
Register the keys to Secure Boot
sudo mokutil --import MOK.der
Supply a password for later use after reboot
Reboot
and follow instructions to Enroll MOK (Machine Owner Key). Here's a sample with pictures. The system will reboot one more time.
Please let me know if your modules would run this way on Ubuntu 16.04 (on kernel 4.4.0-21, I believe).
Resources: Detailed website article for Fedora and Ubuntu implementation of module signing. (they've been working on it) ;-)
Additional note for the security (extra-)conscious: ;-)
Since the private key you created (MOK.priv
in this example) can be used by anyone who can have access to it, it is good practice to keep it secure. You may chmod
it, encrypt (gpg
) it, or store it somewhere else safe(r). Or, as noted in this comment, remove the option -nodes
in step number 1. This will encrypt the key with a passphrase.
edited Apr 13 '17 at 12:23
Community♦
1
1
answered May 9 '16 at 15:19
MajalMajal
4,65032234
4,65032234
On Ubuntu 14.10 I continued to see 'required key not available' trying to install a broadcom driver compiled from source, despite preregistering the key and signing the driver. Disabling validation worked.
– Mark
Jul 16 '16 at 0:37
1
This worked for me for VirtualBox and Ubuntu 16.04.
– YtvwlD
Aug 4 '16 at 11:18
1
I get the following error in step 3: "EFI variables are not supported on this system". "dmesg" has no efi entries ("dmesg | grep efi" has no results) What else can I do? Thanks
– musbach
Jan 7 '17 at 15:55
You can substitute the path in with $(modinfo -n modulename)
– Shane
Aug 7 '17 at 1:56
add a comment |
On Ubuntu 14.10 I continued to see 'required key not available' trying to install a broadcom driver compiled from source, despite preregistering the key and signing the driver. Disabling validation worked.
– Mark
Jul 16 '16 at 0:37
1
This worked for me for VirtualBox and Ubuntu 16.04.
– YtvwlD
Aug 4 '16 at 11:18
1
I get the following error in step 3: "EFI variables are not supported on this system". "dmesg" has no efi entries ("dmesg | grep efi" has no results) What else can I do? Thanks
– musbach
Jan 7 '17 at 15:55
You can substitute the path in with $(modinfo -n modulename)
– Shane
Aug 7 '17 at 1:56
On Ubuntu 14.10 I continued to see 'required key not available' trying to install a broadcom driver compiled from source, despite preregistering the key and signing the driver. Disabling validation worked.
– Mark
Jul 16 '16 at 0:37
On Ubuntu 14.10 I continued to see 'required key not available' trying to install a broadcom driver compiled from source, despite preregistering the key and signing the driver. Disabling validation worked.
– Mark
Jul 16 '16 at 0:37
1
1
This worked for me for VirtualBox and Ubuntu 16.04.
– YtvwlD
Aug 4 '16 at 11:18
This worked for me for VirtualBox and Ubuntu 16.04.
– YtvwlD
Aug 4 '16 at 11:18
1
1
I get the following error in step 3: "EFI variables are not supported on this system". "dmesg" has no efi entries ("dmesg | grep efi" has no results) What else can I do? Thanks
– musbach
Jan 7 '17 at 15:55
I get the following error in step 3: "EFI variables are not supported on this system". "dmesg" has no efi entries ("dmesg | grep efi" has no results) What else can I do? Thanks
– musbach
Jan 7 '17 at 15:55
You can substitute the path in with $(modinfo -n modulename)
– Shane
Aug 7 '17 at 1:56
You can substitute the path in with $(modinfo -n modulename)
– Shane
Aug 7 '17 at 1:56
add a comment |
You can disable Secure Boot (UEFI) in the BIOS with the following steps:
Reboot your machine and enter the BIOS Menu (In my case pressing F2)
Search for Secure Boot and change to Legacy
In an ASUS motherboard:
- Go to the Advanced Mode (F7)
- Go in the Secure Boot option under the Boot section
- Change "Windows UEFI mode" with "Other OS"
- Save and restart to apply settings (F10)
2
Secure Boot and "Legacy" are different settings.
– Pilot6
Aug 12 '16 at 10:53
But if you have "legacy boot" enabled instead of UEFI, does that entail that Secure Boot is not enabled?
– Supernormal
Jan 9 '17 at 15:26
@Supernormal, yes, this is what I understand.
– Sputnik
Nov 17 '17 at 11:22
add a comment |
You can disable Secure Boot (UEFI) in the BIOS with the following steps:
Reboot your machine and enter the BIOS Menu (In my case pressing F2)
Search for Secure Boot and change to Legacy
In an ASUS motherboard:
- Go to the Advanced Mode (F7)
- Go in the Secure Boot option under the Boot section
- Change "Windows UEFI mode" with "Other OS"
- Save and restart to apply settings (F10)
2
Secure Boot and "Legacy" are different settings.
– Pilot6
Aug 12 '16 at 10:53
But if you have "legacy boot" enabled instead of UEFI, does that entail that Secure Boot is not enabled?
– Supernormal
Jan 9 '17 at 15:26
@Supernormal, yes, this is what I understand.
– Sputnik
Nov 17 '17 at 11:22
add a comment |
You can disable Secure Boot (UEFI) in the BIOS with the following steps:
Reboot your machine and enter the BIOS Menu (In my case pressing F2)
Search for Secure Boot and change to Legacy
In an ASUS motherboard:
- Go to the Advanced Mode (F7)
- Go in the Secure Boot option under the Boot section
- Change "Windows UEFI mode" with "Other OS"
- Save and restart to apply settings (F10)
You can disable Secure Boot (UEFI) in the BIOS with the following steps:
Reboot your machine and enter the BIOS Menu (In my case pressing F2)
Search for Secure Boot and change to Legacy
In an ASUS motherboard:
- Go to the Advanced Mode (F7)
- Go in the Secure Boot option under the Boot section
- Change "Windows UEFI mode" with "Other OS"
- Save and restart to apply settings (F10)
answered Apr 28 '16 at 16:08
SputnikSputnik
1054
1054
2
Secure Boot and "Legacy" are different settings.
– Pilot6
Aug 12 '16 at 10:53
But if you have "legacy boot" enabled instead of UEFI, does that entail that Secure Boot is not enabled?
– Supernormal
Jan 9 '17 at 15:26
@Supernormal, yes, this is what I understand.
– Sputnik
Nov 17 '17 at 11:22
add a comment |
2
Secure Boot and "Legacy" are different settings.
– Pilot6
Aug 12 '16 at 10:53
But if you have "legacy boot" enabled instead of UEFI, does that entail that Secure Boot is not enabled?
– Supernormal
Jan 9 '17 at 15:26
@Supernormal, yes, this is what I understand.
– Sputnik
Nov 17 '17 at 11:22
2
2
Secure Boot and "Legacy" are different settings.
– Pilot6
Aug 12 '16 at 10:53
Secure Boot and "Legacy" are different settings.
– Pilot6
Aug 12 '16 at 10:53
But if you have "legacy boot" enabled instead of UEFI, does that entail that Secure Boot is not enabled?
– Supernormal
Jan 9 '17 at 15:26
But if you have "legacy boot" enabled instead of UEFI, does that entail that Secure Boot is not enabled?
– Supernormal
Jan 9 '17 at 15:26
@Supernormal, yes, this is what I understand.
– Sputnik
Nov 17 '17 at 11:22
@Supernormal, yes, this is what I understand.
– Sputnik
Nov 17 '17 at 11:22
add a comment |
You can also Disable Secure Boot in shim-signed running sudo update-secureboot-policy
. This wiki page explains this method:
- Open a terminal (Ctrl + Alt + T), and execute sudo update-secureboot-policy and then select Yes.
- Enter a temporary password between 8 to 16 digits. (For example, 12345678, we will use this password later
- Enter the same password again to confirm.
- Reboot the system and press any key when you see the blue screen (MOK management
- Select Change Secure Boot state
- Enter the password you had selected in Step 2 and press Enter.
- Select Yes to disable Secure Boot in shim-signed.
- Press Enter key to finish the whole procedure.
You can still enable Secure Boot in shim-signed again. Just execute
sudo update-secureboot-policy --enable
and then follow the steps above
add a comment |
You can also Disable Secure Boot in shim-signed running sudo update-secureboot-policy
. This wiki page explains this method:
- Open a terminal (Ctrl + Alt + T), and execute sudo update-secureboot-policy and then select Yes.
- Enter a temporary password between 8 to 16 digits. (For example, 12345678, we will use this password later
- Enter the same password again to confirm.
- Reboot the system and press any key when you see the blue screen (MOK management
- Select Change Secure Boot state
- Enter the password you had selected in Step 2 and press Enter.
- Select Yes to disable Secure Boot in shim-signed.
- Press Enter key to finish the whole procedure.
You can still enable Secure Boot in shim-signed again. Just execute
sudo update-secureboot-policy --enable
and then follow the steps above
add a comment |
You can also Disable Secure Boot in shim-signed running sudo update-secureboot-policy
. This wiki page explains this method:
- Open a terminal (Ctrl + Alt + T), and execute sudo update-secureboot-policy and then select Yes.
- Enter a temporary password between 8 to 16 digits. (For example, 12345678, we will use this password later
- Enter the same password again to confirm.
- Reboot the system and press any key when you see the blue screen (MOK management
- Select Change Secure Boot state
- Enter the password you had selected in Step 2 and press Enter.
- Select Yes to disable Secure Boot in shim-signed.
- Press Enter key to finish the whole procedure.
You can still enable Secure Boot in shim-signed again. Just execute
sudo update-secureboot-policy --enable
and then follow the steps above
You can also Disable Secure Boot in shim-signed running sudo update-secureboot-policy
. This wiki page explains this method:
- Open a terminal (Ctrl + Alt + T), and execute sudo update-secureboot-policy and then select Yes.
- Enter a temporary password between 8 to 16 digits. (For example, 12345678, we will use this password later
- Enter the same password again to confirm.
- Reboot the system and press any key when you see the blue screen (MOK management
- Select Change Secure Boot state
- Enter the password you had selected in Step 2 and press Enter.
- Select Yes to disable Secure Boot in shim-signed.
- Press Enter key to finish the whole procedure.
You can still enable Secure Boot in shim-signed again. Just execute
sudo update-secureboot-policy --enable
and then follow the steps above
edited Oct 14 '16 at 11:41
αғsнιη
24.3k2295156
24.3k2295156
answered Aug 4 '16 at 14:48
Kent LinKent Lin
562
562
add a comment |
add a comment |
protected by Pilot6 Aug 26 '17 at 16:14
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
Similar: askubuntu.com/questions/760671/…
– Tor Klingberg
Feb 26 '18 at 10:50