VB systemd unit persistently rebuilding kernel modules with secureboot

[lxop]

In Debian, the kernel source script extract-module-sig.pl is not available in the kernel modules build/scripts directory. The VirtualBox systemd unit script relies on this script to determine whether the VB kernel modules are appropriately signed if it detects that secureboot is enabled. Since it can't find the script, it believes there is something wrong with the modules, and rebuilds them every time the service starts (at least on every boot), regardless of whether they were correctly signed. This means that every time I reboot my machine, VirtualBox refuses to operate until I go back and sign the newly-built kernel modules.

System: Debian Bullseye VB installed with the deb distributed by the download.virtualbox.org repository.

[galitsyn]

Hi lxop,

If you setup signing environment in your Debian distro (either host or guest), you should not sign modules manually, it should be done automatically (by either rcvboxdrv or rcvboxadd). If it is not a case, let's look at it a bit closer. Could you please double check?

[lxop]

Hi galitsyn,

Thanks for your response. I have a passphrase on the signing key, so it will not be possible to sign the modules automatically (to do so would completely defeat the purpose of secureboot). I don't mind signing the modules manually, but only when the kernel is updated - on every boot is silly.

However, even if I were to make use of automatic signing, the systemd unit script would be (automatically) signing the modules every time it runs, since the lack of extract-module-sig.pl would cause it to believe the modules are unsigned.

Many thanks,

lxop

[lxop]

In addition, if the kernel modules are built/signed/all ok but simply not loaded, the vboxdrv.sh script will consider them broken and rebuild because the vboxmanage -v command includes a big warning banner on stdout, thus confusing the vboxdrv.sh script when it tries to get the version.

[Dave Hawkins]

I'm seeing this same problem using Oracle Linux 8. I haven't dug into the details, but presumably at least one of my problems is that I don't have my private keys in the expected location and have no intention of putting them there. I have resolved this issue by inserting the following line into the start function of /usr/lib/virtualbox/vboxdrv.sh:

$MODPROBE vboxdrv >/dev/null 2>&1

just before:

if ! running vboxdrv; then

If the module is signed properly, it will load. Then the if condition will evaluate to false and rebuilding will be prevented.

[galitsyn]

Hi guys,

On the latest "Development snapshot" (r155730 and newer) from https://www.virtualbox.org/wiki/Testbuilds there is a way to bypass kernel modules signature check by adding:

VBOX_BYPASS_MODULES_SIGNATURE_CHECK="1"

into /etc/virtualbox-guest-additions.conf (for Guest Additions; file needs to be created manually) or into /etc/vbox/vbox.cfg (for host kernel modules). If you sign modules manually, this should do the trick.

[galitsyn]

Replying to galitsyn:

Hi guys,

On the latest "Development snapshot" (r155730 and newer) from https://www.virtualbox.org/wiki/Testbuilds there is a way to bypass kernel modules signature check by adding:

VBOX_BYPASS_MODULES_SIGNATURE_CHECK="1"

into /etc/virtualbox-guest-additions.conf (for Guest Additions; file needs to be created manually) or into /etc/vbox/vbox.cfg (for host kernel modules). If you sign modules manually, this should do the trick.

This is now part of 7.0.8. Closing ticket.