VBox & VMware in SecureBoot Linux (2016 Update) 19

Kernel driver not installed (rc=-1908) The VirtualBox Linux kernel driver (vboxdrv) is either not loaded or there is a permission problem with /dev/vboxdrv. Please reinstall the kernel module by executing 'etc/init.d/vobxdrv setup' as root. If it is available in your distribution, you should install the DKMS package first. This package keeps track of Linux kernel changes and recompiles the vboxdrv kernel module if necessary.

If you have a Linux system running in Secure Boot and you install VirtualBox or VMware player you will see, with some frustration, that you won’t be able to run any VMs.

This post also applies if you are running your system with module signature verification enabled (CONFIG_MODULE_SIG) even if it’s not running in Secure Boot.

This is an old issue, and I’ve already written about it in another post almost 2 years ago, but at this point some degree of imagination is needed to succeed following that guide, so I have finally decided to update it. The reason why it took me so long to update the post is that I haven’t had VirtualBox or VMware player installed for quite a long time.

To install VirtualBox we’ll use the repository:

user@localhost:$ sudo dnf install gcc kernel-devel VirtualBox

Earlier picture shows what you’ll see from the GUI, but if you run it from the console you’ll see:

user@localhost:$ virtualbox
WARNING: The vboxdrv kernel module is not loaded. Either there is no module
available for the current kernel (4.5.7-202.fc23.x86_64) or it failed to
load. Please recompile the kernel module and install it by

sudo /sbin/rcvboxdrv setup

You will not be able to start VMs until this problem is fixed.

Now we have to compile the Kernel Modules for VirtualBox

user@localhost:$ sudo akmods
Checking kmods exist for 4.5.7-202.fc23.x86_64 [ OK ]

If we try to load any of these modules we’ll see the main problem:

user@localhost:$ sudo modprobe -v vboxdrv
insmod /lib/modules/4.5.7-202.fc23.x86_64/misc/vboxdrv.ko
modprobe: ERROR: could not insert 'vboxdrv': Required key not available

And then you’ll realize what the problem is, modprobe is complaining about required key not being available. Which actually means that the module is not signed and therefore cannot be loaded.

Now that you know what the problem is, the solution is quite simple; you just need to sign the module and make sure that the system recognizes the key as valid.

If you already have a X.509 key you can skip the key creation part and go directly to signing the module and enrolling the key. But if you don’t, you’ll need to generate a key to sign any third party module you want to install or any custom module you use.

Creating an X.509 Key Pair to sign the driver is easy:

user@localhost:$ openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -nodes -days 36500 -subj "/CN=Akrog/"

In the above command, replace MOK with the name of the file you want for the key and Akrog with the Common Name you want to use. It’s usually the organization that signs it, but you can write whatever you like, although I recommend a significant name as it will be inserted into the system’s key ring.

VirtualBox uses multiple kernel modules and we need to sign them all. In my previous post I went into a little bit more detail, but I think it’s enough to say that we need to get the location of the modules using modinfo and then signing them using sign-file script like this:

user@localhost:$ for f in $(dirname $(modinfo -n vboxdrv))/*.ko; do echo "Signing $f"; sudo /usr/src/kernels/$(uname -r)/scripts/sign-file sha256 ./MOK.priv ./MOK.der $f; done

If you don’t fee confortable with that script you can do it manually, but be careful, as they may add or remove modules from dirname $(modinfo -n vboxdrv) directory:

user@localhost:$ sudo /usr/src/kernels/$(uname -r)/scripts/sign-file sha256 ./MOK.priv ./MOK.der $(modinfo vboxdrv)

user@localhost:$ sudo /usr/src/kernels/$(uname -r)/scripts/sign-file sha256 ./MOK.priv ./MOK.der $(modinfo vboxguest)

user@localhost:$ sudo /usr/src/kernels/$(uname -r)/scripts/sign-file sha256 ./MOK.priv ./MOK.der $(modinfo vboxnetadp)

user@localhost:$ sudo /usr/src/kernels/$(uname -r)/scripts/sign-file sha256 ./MOK.priv ./MOK.der $(modinfo vboxnetflt)

user@localhost:$ sudo /usr/src/kernels/$(uname -r)/scripts/sign-file sha256 ./MOK.priv ./MOK.der $(modinfo vboxpci)

user@localhost:$ sudo /usr/src/kernels/$(uname -r)/scripts/sign-file sha256 ./MOK.priv ./MOK.der $(modinfo vboxsf)

user@localhost:$ sudo /usr/src/kernels/$(uname -r)/scripts/sign-file sha256 ./MOK.priv ./MOK.der $(modinfo vboxvideo)

Modinfo no longer displays module signed information, so we’ll have to trust that this has worked.

To enroll the public key in the MOK (Module owned Key) your UEFI partition must have MokManager.efi installed. You can check this running

user@localhost:$ sudo find /boot -name MokManager.efi

Now we have to manually add the public key to shim’s MOK list and we’ll be asked for a password that will be used during the UEFI boot to enroll the new key, so make sure you remember it at least for a minute ;-):

user@localhost:$ sudo mokutil --import MOK.der
input password:
input password again:
Failed to write MokAuth
Failed to unset MokNew

Despite the errors I got it seems to work just fine.

What we’ve done with this is request the MOK manager to insert a new key, but we haven’t inserted it yet, so we need to reboot for that and follow the enrolling process that is quite straight forward: Press a key to start the process if you are asked to, then select “Enroll MOK”, then “Continue”, and then “Yes”; and the key has been inserted. This is a persistent operation, so you’ll only need to do this once.

When you have finished booting you can easily check that the key is in the system key ring using the CN we used when creating the X.509 key:

user@localhost:$ keyctl list %:.system_keyring
112560593: ---lswrv 0 0 asymmetric: Fedora kernel signing key: e948c9015e04bd4cd5879fe2f9230a1d70859c7d
489921950: ---lswrv 0 0 asymmetric: Fedora Secure Boot CA: fde32599c2d61db1bf5807335d7b20e4cd963b42
98641885: ---lswrv 0 0 asymmetric: Akrog: d5d3e2008907a7cebc8914780bd29b03fecc214b
525156767: ---lswrv 0 0 asymmetric: Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4
1001714488: ---lswrv 0 0 asymmetric: Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53

And that it was EFI who loaded it:

user@localhost:$ dmesg | grep 'EFI: Loaded cert'
[ 0.456158] EFI: Loaded cert 'Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53' linked to '.system_keyring'
[ 0.456194] EFI: Loaded cert 'Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4' linked to '.system_keyring'
[ 0.457111] EFI: Loaded cert 'Akrog: d5d3e2008907a7cebc8914780bd29b03fecc214b' linked to '.system_keyring'
[ 0.457768] EFI: Loaded cert 'Fedora Secure Boot CA: fde32599c2d61db1bf5807335d7b20e4cd963b42' linked to '.system_keyring'

Now you should be able to run VirtualBox VMs without problem.

For a more detailed description of the process of signing kernel modules you can check Red Hat’s documentation here.

If you read VirtualBox ticket regarding this issue you’ll see they wash their hands on the matter saying: “This is not really a VirtualBox bug. Oracle cannot sign kernel modules using the Fedora key”.
I for one believe that this is a bug in the installation, as they could easilly see if the installation is running on a BIOS or EFI/UEFI system (checking for /sys/firmware/efi directory) and whether Secure Boot is enabled or not (checking the efivar SecureBoot) and if it’s enable request a key to sign the driver or ask you if you want to create one and have it inserted it in the MOK automatically.

VMware signing should be the very similar, unfortunately I cannot check it because the installer won’t work when you have KVM running, as is my case, and even when I disabled KVM modules temporarily and was able to install it, the module compilation using vmware-modconfig wouldn’t work as it should. So I’ll assume we have the VMware player installed and the kernel modules compiled.

For those fighting the VMware installation, it’s worth mentioning that in the older post Pipio was having trouble with VMware and this post in the message board helped in the resolution of the problem.

The last time I run VMware without signed kernel modules the error that was displayed was this:
Error when trying to run VM:    Could not open /dev/vmmon: No such file or directory.    Please make sure that the kernel module `vmmon' is loaded.

So for VMware the signing would be like for VirtualBox, but replacing vboxdrv with vmmon like this:

user@localhost:$ for f in $(dirname $(modinfo -n vmmon))/*.ko; do echo "Signing $f"; sudo /usr/src/kernels/$(uname -r)/scripts/sign-file sha256 ./MOK.priv ./MOK.der $f; done

Ubuntu seems to need a slightly different script (thanks Kinnaird McQuade):

user@localhost:$ for f in $(dirname $(modinfo -n vmmon))/*.ko; do echo “Signing $f”; sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 ./MOK.priv ./MOK.der $f; done

PS: I used Fedora 23, but the signing process should work on any Linux using EFI shim for UEFI boot.

Leave a comment

Your email address will not be published. Required fields are marked *

19 thoughts on “VBox & VMware in SecureBoot Linux (2016 Update)

  • Bane


    I am not sure why after importing the keys and signing the modules, I still get Request for unknown module key ‘BaneC: a1e… err -11, once I try to reload the module? I verified that the key is enrolled in MOK. Any idea?


    • geguileo Post author

      Did you reboot the system and were asked to do the key enrollment process? Did you confirm that the key is present in the system keyring?

  • Andy

    It’s a very good article, thank you very much for explaining it.

    Now let’s make it even better:
    1) Put the keys in some system directory (e.g. /etc/pki/secure-boot).
    2) Make a bash script to sign modules automatically (cuz we’re lazy).
    3) Put the script in /etc/kernel/postinst.d/ to run it automatically after kernel updates.

    Here is my script, feel free to use and modify it (Any improvement is welcome):

    • lowsnr

      Thank you for the script. It works well with the right adaptions to my system, but there is one issue I haven’t been able to resolve. When the script gets to the signing stage it retrieves the kernel part of the file path with ‘uname -r’. The system is apparently running on the old kernel when installing a new version so the files that get signed are those for the old kernel module, not the new ones that I want! Is there a way for the script to find the version of the new kernel being installed? An alternative appears to be if the script gets executed after the reboot when the new kernel first becomes active.
      I’m running a Fedora 26 system.

      Thank you for any advise.

      • geguileo Post author

        Usually you would want to do the signing with the current running kernel, but if you want to sign the latest kernel available in the system you could probably replace “$(uname -r)” with “$(rpm -q kernel | sort | tail -1)”

  • compusam

    Thanks man you save my life,
    I have some days searching for that solutions.

    I do it in Fedora 26 and Virtualbox 5.1 with Kernel 4

    Best Regards

  • Mike

    Great article…was a big help for my other machine. However, when trying to enroll the key with this machine, I get nothing. Zero. I enter the password and it just sits there. This is a “not as old” Dell Inspiron 15 and the other is a “is as old” Samsung 7 Chronos or something. This is the only kernel module that I add outside of what ships with CentOS and I can’t get it to work here. Interestingly, the MOK Manager lets me know when the password is wrong, but does nothing when it’s right. Maybe you’ve heard of similar, but I’ve come up empty on Google so far. Thanks!

      • Mike

        Thanks a lot anyway. I gave up on it as I suspect the UEFI firmware is refusing to cooperate and fixing that, if I can, is more effort than I care to put in after 20 or so years of malware-free Linux. I’m still running it on the other computer, and will continue to, as long as it keeps humming along, Interestingly, the security auditing tool Lynis, when run on the two computers after a fresh install, gave zero security points for Secure Boot, as both computers had the same initial score. I get more points from adding a sshd banner. That’s not to say Lynis is the last word on computer security, but it *is* Secure Boot aware. I suspect that the security tools I do regularly use (IPS, AV, SELinux, etc) along with a moderate dose of common sense will keep me going long enough for Secure Boot to become a little more Linux-friendly. In the meantime, I look at any particular Linux install as a grocery bag, and my data as the groceries. Of course it’s the groceries that are important, and if the bag tears, I just get another one. I have multiple copies of my data, and if I even had an inkling that I was compromised or infected or just trashed my system, (never happened thanks to great early mentors) a re-install disk and an hour of my time and I’m back up. Thanks again for your help and article! The other computer thanks you. 🙂

  • Kinnaird McQuade

    For Ubuntu (not Fedora), the directory in the final script didn’t work. Here’s the right command:
    for f in $(dirname $(modinfo -n vmmon))/*.ko; do echo “Signing $f”; sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 ./MOK.priv ./MOK.der $f; done