Signing VirtualBox Kernel Modules

signing-vbox-kernel-modules.md

Signing VirtualBox Kernel Modules

These are the steps I followed enable VirtualBox on my laptop without disabling UEFI Secure Boot. They're nearly identical to the process described on Øyvind Stegard's blog, save for a few key details. The images here are borrowed from the Systemtap UEFI Secure Boot Wiki.

1. Install the VirtualBox package (this might be different for your platform).

   src='https://download.virtualbox.org/virtualbox/rpm/fedora/virtualbox.repo'
   dst='/etc/yum.repos.d/virtualbox.repo'
   sudo curl ${src} > ${dst}
   dnf check-update
   sudo dnf install VirtualBox-6.0

2. Create an RSA key pair to sign kernel modules.

   name="$(getent passwd $(whoami) | awk -F: '{print $5}')"
   out_dir='/root/module-signing'
   sudo mkdir ${out_dir}
   sudo openssl \
       req \
       -new \
       -x509 \
       -newkey \
       rsa:2048 \
       -keyout ${out_dir}/MOK.priv \
       -outform DER \
       -out ${out_dir}/MOK.der \
       -days 36500 \  # This is probably waaay too long.
       -subj "/CN=${name}/"
   sudo chmod 600 ${out_dir}/MOK*

   Note the absence of the -nodes option from Øyvind's post. With this option openssl will create a private key with no passphrase. The omission of this option prompts for a passphrase, which seems like a good idea for something as important as a kernel module signing key.

3. Import the MOK ("Machine Owner Key") so it can be trusted by the system.

   sudo mokutil --import /root/module-signing/MOK.der

   This will prompt for a password. The password is only temporary and will be used on the next boot. It does not have to be the same as the signing key passphrase.

4. Reboot your machine to enter the MOK manager EFI utility.

   • Select Enroll MOK.

   

   • Select Continue.

   

   • Select Yes to enroll the keys.

   

   • Enter the password from earlier.

   

   • Select OK to reboot.

   

   • Verify the key has been loaded by finding the it in the output of

   dmesg | grep '[U]EFI.*cert'

5. Create a script for signing all the VirtualBox kernel modules.

   #!/bin/sh
   
   readonly hash_algo='sha256'
   readonly key='/root/module-signing/MOK.priv'
   readonly x509='/root/module-signing/MOK.der'
   
   readonly name="$(basename $0)"
   readonly esc='\\e'
   readonly reset="${esc}[0m"
   
   green() { local string="${1}"; echo "${esc}[32m${string}${reset}"; }
   blue() { local string="${1}"; echo "${esc}[34m${string}${reset}"; }
   log() { local string="${1}"; echo "[$(blue $name)] ${string}"; }
   
   # The exact location of `sign-file` might vary depending on your platform.
   alias sign-file="/usr/src/kernels/$(uname -r)/scripts/sign-file"
   
   [ -z "${KBUILD_SIGN_PIN}" ] && read -p "Passphrase for ${key}: " KBUILD_SIGN_PIN
   export KBUILD_SIGN_PIN
   
   for module in $(dirname $(modinfo -n vboxdrv))/*.ko; do
     log "Signing $(green ${module})..."
     sign-file "${hash_algo}" "${key}" "${x509}" "${module}"
   done

   This script differs from Øyvind's in two aspects. First, and most importantly, it has ✨ C O L O R S ✨. Second, it uses the magic $KBUILD_SIGN_PIN environment variable that doesn't appear anywhere in the sign-file usage. I went spelunking in the Linux source for it, but in hindsight I could have just read the docs on manual module signing... I wrote this script to /root/bin/sign-vbox-modules as that's usually on root's $PATH.

6. Execute the aforementioned script as root.

   sudo chmod 700 /root/bin/sign-vbox-modules
   sudo -i sign-vbox-modules

7. Load the vboxdrv module.

   sudo modprobe vboxdrv

I'd like to add a note; I was in the same situation of @hoxsiew, @LizAinslie and @ChrisRoald, rebooting didn't trigger the MokManager utility so that I couldn't enroll the key and modprobe-ing didn't work, saying that the key was rejected by service.
@m4ldonado suggestion didn't work for me, so I had to resort to explicitly create an UEFI entry with:

sudo efibootmgr -c -d /dev/device_containing_the_EFI_partition -p number_of_EFI_partition -L "MokManager" -l '\efi\boot\fedora\mmx64.efi'

checking which entry number it was given with:

efibootmgr -v

and force it to start that entry just for once on reboot with:

sudo efibootmgr -n mokmanager_new_entry_number

Of course, customize your device_containing_the_EFI_partition, number_of_EFI_partition and mokmanager_new_entry_number as per your setup.

N.B.: I'm on Fedora 34 (with SecureBoot enable, of course) and for that \efi\boot\fedora\mmx64.efi is the specific location of the MokManager file, yours might be different.

2° N.B.: all this works wonderfully for the VirtualBox package of the RPMFusion repo; with the one from the VirtualBox site, since this latter apparently regenerates the modules each reboot so that every time they loose the signature, the procedure works only for the current boot and requires signing again at the next boot...

Ah, I've got an interesting update: at least here (on a Lenovo ThinkCentre M920t) an ordinary (and successful) BIOS update wiped the enrolled key, which needed to be re-enrolled as described.

On Fedora 34 (Thinkpad P14s), mok enrollment happened successfully, but after reboot got stuck. GRUB failed to show even the menu. To get back, i had to switch off Secure Boot, delete the key using mokutility. After the deletion, things were back to normal with Secure Boot on.

Any leads ?

had to change the path also in the script and found it using "dpkg -S sign-file" but otherwise this tutorial is very useful. Thanks a lot !

Oracle Linux 8 / Dell 7420 experience:

• It worth to stress that MOK registration is involved process -- doing it step by step is possible only if following the screenshots on other computer. Otherwise it better to memorize the sequence of blue screens.

• dmesg | grep '[U]EFI.*cert' did not work for me. I used mokutil --list-enrolled | grep Subject: to verify that the key is loaded.

• I had to modify signing script:

  • I dislike displaying password, thus read -s -p "...." and echo after that.
  • alias did not work. I replaced with the simple shell variable.
  • output colors did not work -- I added -e to the echo commands.

Thank you @reillysiemens ! you saved me tons of time.

Fedora 35 / Dell XPS 15 9500 experience:

• for the most part alings to what @vadim-or wrote a few weeks earlier,
• getting the MOK registration to come up remained pretty mysterious and involved changing the UEFI-bootorder so instead of the only entry reading Fedora, a different one labeled as the NVME-device present in my system needed to be chosen and afterwards the Fedora one re-selected to finally being presented a screen offering the option of Enroll MOK.
• instead of the also for me not-working I used dmesg | fgrep -i 'loaded X.509 cert' but came to like @vadim-or s solution involving mokutil even better.
• I also don't like displaying passwords but didn't need to echo anything for doing so.

Also, my sincere thanks for this writeup @reillysiemens as I probably would have been stuck with this forever otherwise! 🙏

When installing VirtualBox to Fedora 36 using conventional methods (adding RPM repository and then installing with dnf), I ended up with kernel modules with *.ko.xz extension(vboxdrv.ko.xz, vboxnetadp.ko.xz, vboxnetflt.ko.xz). From what I understand kmods modules were not properly compiled. As a result, when trying to load modules (with modprobe vboxdrv) I got the following error even though I did sign them correctly.

modprobe: ERROR: could not insert 'vboxdrv': Invalid argument

It seems to be an issue specific to Fedora 36, as I had a similar issue with v4l2loopback module. The solution is not to use the default repository to install and instead download the release .rpm files from official sources and install manually. After manually downloading and installing the resulting kmod modules did not have that .xz extension and did load correctly after signing them.

When installing VirtualBox to Fedora 36 using conventional methods (adding RPM repository and then installing with dnf), I ended up with kernel modules with *.ko.xz extension(vboxdrv.ko.xz, vboxnetadp.ko.xz, vboxnetflt.ko.xz). From what I understand kmods modules were not properly compiled. As a result, when trying to load modules (with modprobe vboxdrv) I got the following error even though I did sign them correctly.

modprobe: ERROR: could not insert 'vboxdrv': Invalid argument

It seems to be an issue specific to Fedora 36, as I had a similar issue with v4l2loopback module. The solution is not to use the default repository to install and instead download the release .rpm files from official sources and install manually. After manually downloading and installing the resulting kmod modules did not have that .xz extension and did load correctly after signing them.

I may add that I found the same issue here, on different machines just updated to Fedora 36 - I managed to:

1. decompress the modules
2. sign them as described above
3. recompress the modules

and everything works as before, but the hassle to have it in the right way is becoming a little too much for my tastes...

#!/bin/sh

readonly hash_algo='sha256'
readonly key='/root/module-signing/MOK.priv'
readonly x509='/root/module-signing/MOK.der'

readonly name="$(basename $0)"
readonly esc='\\e'
readonly reset="${esc}[0m"

green() { local string="${1}"; echo "${esc}[32m${string}${reset}"; }
blue() { local string="${1}"; echo "${esc}[34m${string}${reset}"; }
log() { local string="${1}"; echo "[$(blue $name)] ${string}"; }

# The exact location of `sign-file` might vary depending on your platform.
alias sign-file="/usr/src/kernels/$(uname -r)/scripts/sign-file"

[ -z "${KBUILD_SIGN_PIN}" ] && read -p "Passphrase for ${key}: " KBUILD_SIGN_PIN
export KBUILD_SIGN_PIN

for module in $(dirname $(modinfo -n vboxdrv))/*.ko.xz; do
    if [[ $(basename "${module}" .xz) != "${module}" ]]; then
	log "decompress module ${module}"
	xz -d ${module}
    fi
    path=$(dirname "${module}")
    decompressed=$(basename "${module}" .xz)
    log "Signing $(green ${module})..."
    sign-file "${hash_algo}" "${key}" "${x509}" "${path}/${decompressed}"
    if [[ $(basename "${module}" .xz) != "${module}" ]]; then
	log "recompress module ${module}"
	xz "${path}"/"${decompressed}" 
    fi
done

This deals with compressed kernel modules if found (fedora36)

The main solution worked for me on Fedora 36, no error message when starting Virtualbox aftwerwads.

However, after a reboot, the error showed up again, and I hat to rerun the script and reload the modules (steps 6 & 7). Any ideas as to why this would happen again?

P.S.: the colors didn't work for me, but that is unimportant...

On Debian 11 Bullseye, I had to make some changes but it worked fine overall.

This were the changes:

alias sign-file="/usr/src/linux-headers-5.10.0-17-amd64/scripts/sign-file"

for module in $(dirname $(/sbin/modinfo -n vboxdrv))/*.ko; do

and I needed to execute /sbin/modprobe vboxdrv at the end.

Thanks a lot.

#!/bin/sh

readonly hash_algo='sha256'
readonly key='/root/module-signing/MOK.priv'
readonly x509='/root/module-signing/MOK.der'

readonly name="$(basename $0)"
readonly esc='\\e'
readonly reset="${esc}[0m"

green() { local string="${1}"; echo "${esc}[32m${string}${reset}"; }
blue() { local string="${1}"; echo "${esc}[34m${string}${reset}"; }
log() { local string="${1}"; echo "[$(blue $name)] ${string}"; }

# The exact location of `sign-file` might vary depending on your platform.
alias sign-file="/usr/src/kernels/$(uname -r)/scripts/sign-file"

[ -z "${KBUILD_SIGN_PIN}" ] && read -p "Passphrase for ${key}: " KBUILD_SIGN_PIN
export KBUILD_SIGN_PIN

for module in $(dirname $(modinfo -n vboxdrv))/*.ko.xz; do
    if [[ $(basename "${module}" .xz) != "${module}" ]]; then
	log "decompress module ${module}"
	xz -d ${module}
    fi
    path=$(dirname "${module}")
    decompressed=$(basename "${module}" .xz)
    log "Signing $(green ${module})..."
    sign-file "${hash_algo}" "${key}" "${x509}" "${path}/${decompressed}"
    if [[ $(basename "${module}" .xz) != "${module}" ]]; then
	log "recompress module ${module}"
	xz "${path}"/"${decompressed}" 
    fi
done

This deals with compressed kernel modules if found (fedora36)

The official package does not provide compressed modules. Note that this script probably is meant for another rpmfusion package maybe?

The only thing that worries me is about the security perspective. The akmod private key is not password protected, so... just in case someone takes control of my machine, he/she could signs a malicious module using akmod. That module would be correctly loaded because that key had already been imported by me using MOK. Any consideration about that?

@vash83a I put my keys on an encrypted thumb drive that I only insert and mount when I'm resigning modules. You need to tweak some paths to get it to work, but it resolves the larger security issue.

i have 2 issues:

1. dmesg | grep '[U]EFI.*cert' has no output after i enroll MOK.

2. when i run sign-vbox-modules , i got prompted for passphrase and got error writing the keys.

I just realised the VirtualBox installer will sign the modules for you (at least on Ubuntu 22.04) but I didn't pick this up straight away because when I ran /sbin/vboxconfig I received the error that I needed to sign the modules. But there were no modules to sign!

My issue turned out to be I was missing make which was in the error message, but displayed after the message about signing the modules.

It actually mentions installing gcc, make and perl: sudo apt install gcc make perl -y

Hi, fix work fine (edupr91 - version), on fedora 37

But there is a way not to ask key :

Passphrase for /root/module-signing/MOK.priv:

every reboot i need to insert it.

Thank you

Hi,
updated to Fedora 38, same notice to insert passfrase

this may be offtopic, but after spending an hour trying to get these modules signed on my Ubuntu 22.04 desktop, I realized that /sbin/vboxconfig was actually trying to build and sign them for me - however when viewing the log with cat /var/log/vbox-setup.log I saw that it was trying to run gcc-12 and I only had gcc-11 installed for some reason.

After installing gcc-12 and then re-running sudo /sbin/vboxconfig everything "just worked"!

this may be offtopic, but after spending an hour trying to get these modules signed on my Ubuntu 22.04 desktop, I realized that /sbin/vboxconfig was actually trying to build and sign them for me - however when viewing the log with cat /var/log/vbox-setup.log I saw that it was trying to run gcc-12 and I only had gcc-11 installed for some reason.

After installing gcc-12 and then re-running sudo /sbin/vboxconfig everything "just worked"!

Same thing I posted above https://gist.github.com/reillysiemens/ac6bea1e6c7684d62f544bd79b2182a4?permalink_comment_id=4491378#gistcomment-4491378. I spent hours trying to fix it following all the advice above, before reading the error telling me I didn't have the prerequisites installed. Hopefully more people see our posts and check this is not their issue before going down the rabbit hole.

@DylanMunyard I actually tried what you listed as well: sudo apt install gcc make perl -y , however I already had those packages installed
For some reason it specifically wanted gcc-12! (possibly because I'm running the newest kernel and that was built with gcc-12?)

I was able to fix this under Ubuntu 22.04 LTE, running the HWE (Hardware Enablement) stack with the latest kernel 5.19.0-50-generic, for Virtualbox 7.0.10r158379 with this command:

sudo mokutil --import /var/lib/shim-signed/mok/MOK.der

Check out this thread for Ubuntu: https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1992673

My understanding is that Secure Boot is a feature that allows manufacturers, OS creators, and users, to enroll signing keys MOK (Machine Owner Key), to enable various OSes to ensure they are running kernel and device driver code that has been signed by a trusted entity. Microsoft has a key it enrolls with popular manufacturers, but the various Linux distros do not. That "shim-signed" file is the private key for Ubuntu and Debian. That Linux MOK file needs to be manually trusted using mokutil.

I was able to get Virtualbox to temporarily run by following the instructions here, but after reboot, Virtualbox would still fail to load. What I found odd was that running sudo modprobe vboxdrv would give an error of modprobe: ERROR: could not insert 'vboxdrv'" Key was rejected by service. and in dmesg of Loading of module with unavailable key is rejected, despite the Virtualbox kernel modules being signed by a trusted MOK. I then realized that there was probably another MOK being used and ran find / -iname MOK.der to find the file /var/lib/shim-signed/mok/MOK.der, and read more about it.

You'll need to rerun that command if you do a BIOS update.

• https://wiki.debian.org/SecureBoot
• https://packages.debian.org/sid/shim-signed

Thank you very much for your help.
It works perfectly on debian 11

Thanks, it works for Fedora 38 and Virtualbox 7.0.

Regards

For opensuse 15.5 I found that, you have to generate ssh keys with this command:
sudo openssl req -nodes -new -x509 -newkey rsa:2048 -outform DER -addext "extendedKeyUsage=codeSigning" -keyout /var/lib/shim-signed/mok/MOK.priv -out /var/lib/shim-signed/mok/MOK.der
In this command is addtext for code signing. With this key it worked fine.
Thanks for your guide.

I am using Ubuntu 22.04. I followed the steps as mentioned but when ran sudo -i sign-vbox-modules, I am getting this error,

-bash: line 1: sign-vbox-modules: command not found

Could anyone help?

I'm on Debian Sid and there's any easy (and more automatic way) to sign Virtualbox (and other) modules. This will probably apply to other Debian versions and possibly other distros. In Debian Virtualbox modules are already signed by dkms if compiled by installing the virtualbox-dkms package. The problem is that the key generated and used by dkms is not recognised in the system, so we need to add that particular one to MOK. If you go to /var/lib/dkms you should have a mok.pub and a mok.key file. If so, then issue the command:
mokutil --import /var/lib/dkms/mok.pub
and your pc will enroll the key used by dkms. This way all the modules built by the service will be able to load at startup and on every kernel update automatically.

This is super helpful this post finally helped me a lot with this issue which I tried to solve for many months. I knew what needs to be done, however many updates of system / bios upgraded / etc caused that my solutions didn't work any longer - and this post helped to solved. Thank you.

Some one have tested with Fedora 40 ?

In Fedora Linux 41:

After being prompted with this:
Passphrase for /root/module-signing/MOK.priv:

I got this error:

[\\e[34mvboxsign.sh\\e[0m] Signing \\e[32m/lib/modules/6.12.6-200.fc41.x86_64/extra/VirtualBox/*.ko\\e[0m...
At main.c:302:
- 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: /lib/modules/6.12.6-200.fc41.x86_64/extra/VirtualBox/*.ko

It worked for me on Asus Zenbook.

What the heck. This complexity is hilarious for getting VirtualBox to run. A perfect example why Windows is still king for every-day use ;-) I also ended up disabling SecureBoot as it was not working on my Fedora34 installation on a Huawei Matebook

There are Windows people who don't mind to be sitting and watching chasing nuts on the screen for an hour, and there are Linux people, who don't mind to work for 5 minutes. :)