Virtualbox kernel driver no loading - secureboot enabled - how to sign modules?

English Virtualization
#1

After installing virtualbox from the main repo, I get this error message when trying to start a VM:

Kernel driver not installed (rc=-1908)

The VirtualBox Linux kernel driver is either not loaded or not set up correctly. Please try setting it up again by executing

‘/sbin/vboxconfig’

as root.

If your system has EFI Secure Boot enabled you may also need to sign the kernel modules (vboxdrv, vboxnetflt, vboxnetadp, vboxpci) before you can load them. Please see your Linux system’s documentation for more information.

where: suplibOsInit what: 3 VERR_VM_DRIVER_NOT_INSTALLED (-1908) - The support driver is not installed. On linux, open returned ENOENT.

Installed version:

# zypper se -s VirtualBox
Carregando dados do repositório...
Lendo os pacotes instalados...

S  | Name                           | Type   | Version                     | Arch        | Repository
---+--------------------------------+--------+-----------------------------+-------------+----------------
   | python3-virtualbox             | pacote | 6.1.20-lp153.1.8            | x86_64      | Main Repository
i+ | virtualbox                     | pacote | 6.1.20-lp153.1.8            | x86_64      | Main Repository
   | virtualbox-devel               | pacote | 6.1.20-lp153.1.8            | x86_64      | Main Repository
   | virtualbox-guest-desktop-icons | pacote | 6.1.20-lp153.1.8            | noarch      | Main Repository
   | virtualbox-guest-source        | pacote | 6.1.20-lp153.1.8            | noarch      | Main Repository
   | virtualbox-guest-tools         | pacote | 6.1.20-lp153.1.8            | x86_64      | Main Repository
   | virtualbox-guest-x11           | pacote | 6.1.20-lp153.1.8            | x86_64      | Main Repository
   | virtualbox-host-source         | pacote | 6.1.20-lp153.1.8            | noarch      | Main Repository
i  | virtualbox-kmp-default         | pacote | 6.1.20_k5.3.18_57-lp153.1.2 | x86_64      | Main Repository
   | virtualbox-kmp-preempt         | pacote | 6.1.20_k5.3.18_57-lp153.1.2 | x86_64      | Main Repository
i  | virtualbox-qt                  | pacote | 6.1.20-lp153.1.8            | x86_64      | Main Repository
   | virtualbox-vnc                 | pacote | 6.1.20-lp153.1.8            | x86_64      | Main Repository
   | virtualbox-websrv              | pacote | 6.1.20-lp153.1.8            | x86_64      | Main Repository

Journalctl shows these errors::

# journalctl | grep -i box
jun 10 04:18:49 bruno-03 systemd[1]: Starting VirtualBox Linux kernel module...
jun 10 04:18:49 bruno-03 vboxdrv.sh[1377]: vboxdrv.sh: Starting VirtualBox services.
jun 10 04:18:49 bruno-03 vboxdrv.sh[1473]: Starting VirtualBox services.
jun 10 04:18:49 bruno-03 vboxdrv.sh[1482]: Sources for building host modules are not present,
jun 10 04:18:49 bruno-03 vboxdrv.sh[1482]: Use 'sudo zypper install virtualbox-host-source kernel-devel kernel-default-devel' to install them. Quitting ..
jun 10 04:18:49 bruno-03 vboxdrv.sh[1377]: vboxdrv.sh: failed: modprobe vboxdrv failed. Please use 'dmesg' to find out why.
jun 10 04:18:49 bruno-03 vboxdrv.sh[1505]: failed: modprobe vboxdrv failed. Please use 'dmesg' to find out why.
jun 10 04:18:49 bruno-03 systemd[1]: vboxdrv.service: Control process exited, code=exited, status=1/FAILURE
jun 10 04:18:49 bruno-03 systemd[1]: vboxdrv.service: Failed with result 'exit-code'.
jun 10 04:18:49 bruno-03 systemd[1]: Failed to start VirtualBox Linux kernel module.
jun 10 04:18:49 bruno-03 systemd[1]: Starting vboxautostart-service.service...
jun 10 04:18:49 bruno-03 vboxautostart-service.sh[1506]: vboxautostart-service.sh: Starting VirtualBox VMs configured for autostart.
jun 10 04:18:49 bruno-03 vboxautostart-service.sh[1509]: Starting VirtualBox VMs configured for autostart.
jun 10 04:18:49 bruno-03 vboxautostart-service.sh[1506]: vboxautostart-service.sh: failed: VirtualBox kernel module not loaded!.
jun 10 04:18:49 bruno-03 vboxautostart-service.sh[1512]: failed: VirtualBox kernel module not loaded!.
jun 10 04:18:49 bruno-03 systemd[1]: Started vboxautostart-service.service.
jun 10 04:19:01 bruno-03 akonadiserver[2267]: org.kde.pim.akonadiserver: Subscriber Akonadi::Server::NotificationSubscriber(0x7ff3c818fdf0) identified as "UnifiedMailboxChangeRecorder - 140720374423776"
jun 10 04:20:29 bruno-03 VirtualBoxVM[2711]: QSettings::value: Empty key passed
jun 10 04:20:29 bruno-03 VirtualBoxVM[2711]: QSettings::value: Empty key passed

Apparently I need to sign the modules, according to https://gist.github.com/gabrieljcs/68939c7eeadfabfdbc6b40100130270d , but it seems convoluted.

How can I do this?

Thanks

Bruno

#2

P.S.: Leap 15.3 was installed from the GM disk without internet connection, and is not updated yet due to the huge conflicts that are happening with the current patches.

#3

See https://doc.opensuse.org/release-notes/x86_64/openSUSE/Leap/15.3/#driver-hardware-secure-boot-opensuse-kmps

#4

Thanks, arvidjaar. I’ve done that when I installed the nvidia drivers, but the installation script took care of signing the nvidia modules, I can’t seem to find out how to sign the vbox modules.

openSUSE-signkey-cert was installed from the start, and contains:


/etc/uefi/certs> ls -l
total 12
-rw-r--r-- 1 root root 1288 mai  6 09:13 4AAA0B54.crt
-rw-r--r-- 1 root root 1257 mai  6 11:54 BCA4E38E-shim.crt
-rw-r--r-- 1 root root 1177 mai  3 04:25 BDD31A9E-kmp.crt

The only vbox module installed from the main repo was:


/lib/modules/5.3.18-57-default/kernel/drivers/virt/vboxguest> ls -l
total 20
-rw-r--r-- 1 root root 16672 mai  6 09:18 vboxguest.ko.xz

So I decided to compile the modules, which went OK but couldn’t be inserted:


# /sbin/vboxconfig
Building kernel modules...
Kernel modules built correctly. They will now be installed.
insmod /lib/modules/5.3.18-57-default/extra/vboxdrv.ko 
modprobe: ERROR: could not insert 'vboxnetflt': Operation not permitted
insmod /lib/modules/5.3.18-57-default/extra/vboxdrv.ko 
modprobe: ERROR: could not insert 'vboxnetadp': Operation not permitted
Kernel modules are installed and loaded.

The compiled modules are:


/lib/modules/5.3.18-57-default/extra> ls -l
total 1744
-rw-r--r-- 1 root root 762563 abr 29 12:50 vboxdrv.ko
-rw-r--r-- 1 root root 660267 abr 29 12:50 vboxguest.ko
-rw-r--r-- 1 root root  20995 abr 29 12:50 vboxnetadp.ko
-rw-r--r-- 1 root root  59947 abr 29 12:50 vboxnetflt.ko
-rw-r--r-- 1 root root 165747 abr 29 12:50 vboxsf.ko
-rw-r--r-- 1 root root 101723 abr 29 12:50 vboxvideo.ko

I don’t want to disable secureboot, and in this ASUS mobo UEFI it is not straightforward, I have do delete the PK key but the BIOS is not showing the USB stick to save the key so I can enable it back, AFAICS.

I suppose I have to use mokutil with the BDD31A9E-kmp.crt certificate to sign the modules, but I don’t have the first idea on how to do it.

Any help will be greatly appreciated.

Thanks,

Bruno

#5

Maybe see here:
https://bugzilla.opensuse.org/show_bug.cgi?id=1186784

#6

Yes, as it turns out the modules are signed. vboxdrv, for instance, shows the same signature as in the bug report:


# modinfo vboxdrv
filename:       /lib/modules/5.3.18-57-default/extra/vboxdrv.ko
version:        6.1.20_SUSE r143896 (0x00300000)
license:        GPL
description:    Oracle VM VirtualBox Support Driver
author:         Oracle Corporation
suserelease:    SLE15-SP3
srcversion:     4BA14177643D42355F49C17
depends:        
retpoline:      Y
name:           vboxdrv
vermagic:       5.3.18-57-default SMP mod_unload modversions 
sig_id:         PKCS#7
signer:         openSUSE Secure Boot CA
sig_key:        FA:BE:D8:BF:40:9A:5E:64
sig_hashalgo:   sha256
signature:      43:6D:C0:F5:6C:2E:31:1E:6F:35:B4:C1:8C:F1:49:CF:DF:CF:80:90:
                BB:B1:90:40:B5:24:60:84:A0:74:88:DF:72:53:E0:24:AB:DD:36:42:
                35:EC:90:67:B2:68:B3:CC:27:99:9B:9C:D6:A5:C3:2E:B5:82:93:C2:
                D0:DD:67:0B:4E:2A:FF:7D:17:9F:E3:DE:14:4E:75:55:30:10:02:74:
                C9:8F:C9:7C:4C:7F:72:46:58:36:3E:11:5E:A7:D0:53:4A:00:57:93:
                DC:16:51:72:4E:7E:AE:58:45:6A:37:76:04:C3:12:CE:9C:12:FF:B2:
                02:EB:90:81:84:9E:AE:0C:60:82:14:4E:48:DB:CA:60:FF:43:7F:29:
                5C:30:ED:26:87:FC:79:A2:74:3B:01:5F:DF:AD:50:AA:3F:EF:F2:FB:
                DD:E8:1B:58:4F:A0:4E:4C:18:7A:58:03:E4:A4:A9:A8:F4:92:60:3E:
                DF:75:83:E5:29:FE:9C:61:CF:B1:4C:9D:2A:D9:99:24:4C:FC:3F:6E:
                CD:69:37:46:85:21:17:D7:42:E7:17:23:7B:31:54:A0:97:D4:16:ED:
                91:82:2F:E6:52:97:0C:38:65:84:9D:C1:22:CA:ED:AD:1F:9E:99:45:
                64:C9:BD:D6:49:20:B1:54:CC:E8:27:20:23:EE:EC:8A
parm:           force_async_tsc:force the asynchronous TSC mode (int)

The other modules have their signatures too.

So apparently it is a problem of UEFI not recognizing the signatures, and there is no workaround at this time.

Thanks to all that replied and to Larry Finger, to whom the bug was assigned.

#7

and there is no workaround at this time.

Disable secure boot…

#8

That’s what I don’t want to do, as explained in one of the threads above.

however, on further reading the bug report, user Link Porterfield was able to enroll the openSUSE key. AFAIU the bug is just that only SUSE enterprise keys are initially enrolled. See https://bugzilla.opensuse.org/show_bug.cgi?id=1186784#c14

To fix it I did:

Check if mokutil -N shows a key with Issuer: CN=openSUSE Secure Boot CA. If not, remove & reinstall openSUSE-signkey-cert (not sure if this would happen).
Reboot, choose to enroll the new key, use root password.

Apparently there is an alternative mode using

mokutil -i /etc/uefi/certs/BDD31A9E-kmp.crt

But I didn’t need it.

Now both SUSE Enterprise and openSUSE, as well as nvidia keys, are show in mokutil -l.
And that was it :wink:

#9

I have secure bott disabled, so secure is this setting not…

#10

I am apparently running into the same issue. Just installed Leap 15.3 (three days ago - 06/13/21) and the system is running fine. When I attempted to start VirtualBox this morning using a vdi from my Leap 15.2 machine, I received the message, “Kernel driver not installed (rc=-1908)” along with the note about EFI Secure Boot. I also noted the driver issue while monitoring bootup (“Failed” in red flashes every time) and confirmed this upon checking the boot log.

Although I uninstalled and reinstalled the signkey certificate in YaST (openSUSE-signkey-cert-20210302-lp153.1.1) as suggested in https://bugzilla.opensuse.org/show_bug.cgi?id=1186784#c14, # mokutil -l reports that MokListRT is empty. Should I use a different command to detect the certificate?

The motherboard is an ASUS X99 Deluxe. I see that I can disable secure boot by booting from the usb iso and then deleting the Platform Key.

Of the various options discussed in this thread, disabling secure boot apparently solves the kernel driver issue and might be the route I should take, but I don’t know if this would lead to other problems.

Please let me know what you would recommend.

#11

Did you reboot after installation?

#12

Yes, I did reboot and the error remains. Also, immediately after post, a warning about the lack of a secret EFI key appears (this has been present from the initial install). From the warn log:

EFI secret key getting failed: EFI_NOT_FOUND 0x800000000000000e
EFI secret key size 0 is less than 64. Please regenerate secret key

In the interim I disabled secure boot, on reboot the EFI secret key warning was not present, but VirtualBox was still unable to start the machine, now stating there is now an issue with virtualization:

Failed to open a session for the virtual machine win7-1.
VT-x is disabled in the BIOS for all CPU modes (VERR_VMX_MSR_ALL_VMX_DISABLED).

In BIOS, I see that virtualization is disabled [Advanced > CPU configuration > Intel Virtualization Technology: Disabled].

I re-enabled secure boot and the original driver error re-appears.

So, yes, I did reboot a number of times.

Would enabling virtualization and disabling secure boot work? Or should I seek another solution?

#13

I see from my notes going back at least five years that I did previously enable virtualization in BIOS (and it makes sense that this would be needed).

In the interim, I decided to try what I proposed in my last post: enabling virtualization and disabling secure boot. And that works!

My customizations didn’t carry over, but I can copy and then insert configuration files from the originating machine or re-configure the new machine OS and apps.

I still need to determine if the lack of secure boot will be an issue going forward.

#14

On reboot immediately following installation of openSUSE-signkey-cert you should see MokManager interface requesting you to enroll these keys. Installation of package only creates enrollment request; enrollment itself must be done before OS (and bootloader) are started. If you have not seen MokManager, nothing was enrolled at all. Enrollment requests are cleared by shim, so they are valid for one reboot only.

Also, immediately after post, a warning about the lack of a secret EFI key appears (this has been present from the initial install). From the warn log:

EFI secret key getting failed: EFI_NOT_FOUND 0x800000000000000e
EFI secret key size 0 is less than 64. Please regenerate secret key

Is it exact message? It could be the reason why MokManager is not started, but I do not see this error string in shim sources. Please post photo of this error.

#15

arvidjaar -

I did not get a MOK management request, although I expected one. (I did receive such a request when I installed 15.2 on a Dell laptop this past February.)

Joel

#16

I’m experiencing this on a Lenovo G505s laptop – AMD CPU – not new, at all …
The openSUSE certificates are refusing to enroll – I’m beginning to suspect that this hardware is EOL and, will run with Secure Boot disabled until it finally dies …

#17

dcurtisfra -

I have disabled secure boot on a relatively new machine and it runs fine. I acknowledge that this poses a security risk.

#18

@Everyone:

Continuing with this Laptop –


 # inxi --admin --filter --cpu --machine
Machine:   Type: Laptop System: LENOVO product: 20255 v: Lenovo G505s serial: <filter> Chassis: type: 10 
           v: Lenovo G505s serial: <filter> 
           Mobo: LENOVO model: Lenovo G505s v: 31900003Std serial: <filter> UEFI: LENOVO v: 83CN53WW(V3.00) 
           date: 01/08/2014 
CPU:       Topology: Quad Core model: AMD A10-5750M APU with Radeon HD Graphics bits: 64 type: MCP arch: Piledriver 
           family: 15 (21) model-id: 13 (19) stepping: 1 microcode: 6001119 L1 cache: 192 KiB L2 cache: 2048 KiB 
           flags: avx lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm bogomips: 19961 
           Speed: 1328 MHz min/max: 1400/2500 MHz boost: enabled Core speeds (MHz): 1: 1359 2: 1362 3: 1199 4: 1217 
           Vulnerabilities: Type: itlb_multihit status: Not affected 
           Type: l1tf status: Not affected 
           Type: mds status: Not affected 
           Type: meltdown status: Not affected 
           Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via prctl and seccomp 
           Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization 
           Type: spectre_v2 mitigation: Full AMD retpoline, STIBP: disabled, RSB filling 
           Type: srbds status: Not affected 
           Type: tsx_async_abort status: Not affected 
 #
  1. The MOK “Blue Screen” at boot assumes a US Keyboard layout – if another keyboard change the root password to something which only uses those common between your
    keyboard and the US Keyboard layout … 1. From the systemd “Rescue” system state, tried resetting the MOK list; clearing the MokManage password (MokPW); enrolling the BCA4E38E-shim certificate; enrolling the BDD31A9E-kmp.crt openSUSE sign key certificate …
  2. Nothing, no go – the (older) Lenovo UEFI will not behave …
  3. Reverted back to –

 # mokutil --sb-state 
SecureBoot disabled
 #
#19

@Everyone:

More info – upgraded my Desktop machine to Leap 15.3 – after some effort, Oracle VirtualBox is running with UEFI Secure Boot and TPM enabled …


 # inxi --admin --filter --cpu --machine
Machine:   Type: Desktop Mobo: ASUSTeK model: PRIME B450-PLUS v: Rev X.0x serial: <filter> UEFI: American Megatrends v: 3002 
           date: 03/11/2021 
CPU:       Topology: Quad Core model: AMD Ryzen 5 3400G with Radeon Vega Graphics bits: 64 type: MT MCP arch: Zen+ 
           family: 17 (23) model-id: 18 (24) stepping: 1 microcode: 8108109 L1 cache: 384 KiB L2 cache: 2048 KiB 
           L3 cache: 4096 KiB 
           flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm bogomips: 59091 
           Speed: 1726 MHz min/max: 1400/3700 MHz boost: enabled Core speeds (MHz): 1: 1884 2: 1401 3: 1402 4: 1403 5: 1856 
           6: 1409 7: 1407 8: 1400 
           Vulnerabilities: Type: itlb_multihit status: Not affected 
           Type: l1tf status: Not affected 
           Type: mds status: Not affected 
           Type: meltdown status: Not affected 
           Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via prctl and seccomp 
           Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization 
           Type: spectre_v2 mitigation: Full AMD retpoline, IBPB: conditional, STIBP: disabled, RSB filling 
           Type: srbds status: Not affected 
           Type: tsx_async_abort status: Not affected 
eck001:/root # 
 # mokutil --sb-state
SecureBoot enabled
 # 
 # journalctl -b 0 --output=short-monotonic --no-hostname | grep -i 'tpm'
    0.000000] kernel: efi: ACPI=0xca7d1000 ACPI 2.0=0xca7d1014 TPMFinalLog=0xcaa9d000 SMBIOS=0xcb816000 SMBIOS 3.0=0xcb815000 MEMATTR=0xc6f67018 ESRT=0xc90a1198 MOKvar=0xc6ef7000 RNG=0xcb846f98 TPMEventLog=0x9011a018 
    0.004902] kernel: ACPI: TPM2 0x00000000CA7A3000 00004C (v03 ALASKA A M I    00000001 AMI  00000000)
    8.361478] udevadm[549]: systemd-udev-settle.service is deprecated. Please fix wickedd.service, tpm2-abrmd.service not to pull it in.
    8.631727] systemd[1]: Starting TPM2 Access Broker and Resource Management Daemon...
    8.660651] tpm2-abrmd[1234]: tcti_conf before: "device:/dev/tpm0"
    8.660941] tpm2-abrmd[1234]: tcti_conf after: "device:/dev/tpm0"
    8.699281] systemd[1]: Started TPM2 Access Broker and Resource Management Daemon.
 # 
 # systemctl status vboxdrv.service 
● vboxdrv.service - VirtualBox Linux kernel module
     Loaded: loaded (/usr/lib/virtualbox/vboxdrv.sh; disabled; vendor preset: disabled)
     Active: active (exited) since Wed 2021-07-14 19:48:35 CEST; 24min ago
    Process: 1236 ExecStart=/usr/lib/virtualbox/vboxdrv.sh start (code=exited, status=0/SUCCESS)

Jul 14 19:48:35 xxx systemd[1]: Starting VirtualBox Linux kernel module...
Jul 14 19:48:35 xxx vboxdrv.sh[1236]: vboxdrv.sh: Starting VirtualBox services.
Jul 14 19:48:35 xxx vboxdrv.sh[1298]: Starting VirtualBox services.
Jul 14 19:48:35 xxx vboxdrv.sh[1236]: vboxdrv.sh: You must sign these kernel modules before using VirtualBox:
Jul 14 19:48:35 xxx vboxdrv.sh[1236]:   vboxdrv vboxnetflt vboxnetadp
Jul 14 19:48:35 xxx vboxdrv.sh[1236]: See the documenatation for your Linux distribution..
Jul 14 19:48:35 xxx vboxdrv.sh[1299]: You must sign these kernel modules before using VirtualBox:
                                           vboxdrv vboxnetflt vboxnetadp
                                         See the documenatation for your Linux distribution..
Jul 14 19:48:35 xxx systemd[1]: Started VirtualBox Linux kernel module.
 #

The trick is –

  1. Use the VirtualBox version 6.1.22-lp153.2.3.2 package from the Leap 15.3 update repository – <http://download.opensuse.org/update/leap/15.3/oss> – The package in the Virtualisation repository <https://download.opensuse.org/repositories/Virtualization/openSUSE_Leap_15.3/> isn’t signed with the correct key.
  2. Make sure that, the EFI key included in the “openSUSE-signkey-cert” has been enrolled.

It seems that, 2 keys have to be enrolled – “mokutil --list-enrolled”

  • One with the issuer “CN=SUSE Linux Enterprise Secure Boot CA” – “Subject: CN=SUSE Linux Enterprise Secure Boot CA”.
  • The other with the issuer “CN=openSUSE Secure Boot CA” – “Subject: CN=openSUSE Secure Boot Signkey”.

Assuming that, the host hardware has a UEFI which is new enough to allowed these keys to be enrolled …