vboxdrv failed to build - Virtualbox 5.2.12 r122591 Linux Fedora 28 x86_64

[Max E]

Kernel module vboxdrv is VERY broken on Fedora 28 Cannot build on Fedora 28 - 4.17.3-200.fc28.x86_64

Please see dmesg log and output from /var/log/vbox-install.log

[Max E]

dmesg-failure-log

[Max E]

vbox-install log file failure - Fedora 28

[Max E]

Failure on command line:

vboxconfig vboxdrv.sh: Stopping VirtualBox services. vboxdrv.sh: Building VirtualBox kernel modules. vboxdrv.sh: Starting VirtualBox services. vboxdrv.sh: Building VirtualBox kernel modules. vboxdrv.sh: failed: modprobe vboxdrv failed. Please use 'dmesg' to find out why.

There were problems setting up VirtualBox. To re-start the set-up process, run

/sbin/vboxconfig

as root.

[Max E]

As a workaround, this came down to the fact that I was using UEFI and Secure Boot. What I've done - is temporarily disabled Secure Boot (not ideal).

There is a workaround, but it is a hack. The basic premise of the problem is that the vboxdrv needs to be signed - with a x509 key and it isn't. Therefore, you have to go through the following processes to get it work. My laptop (its a Dell Latitude) did't like even signing the module - until I had disabled Secure Boot first, then it went through the process of installing the signing to the module on the next boot.

All very odd.

Workaround can be found here (its a Debian page, so some of the kernel references need changing, but the basic premise is sound).

​https://askubuntu.com/questions/760671/could-not-load-vboxdrv-after-upgrade-to-ubuntu-16-04-and-i-want-to-keep-secur

[Max E]

Choices are:

Disabled Secure Boot - and build kernel modules correctly

or

Sign the module as part of the .sh script - if the detected kernel is shown as secure boot (Oracle Dev types to the rescue).

or

Sign the kernel module yourself (see URL above).

[Michael Thayer]

Option 2) is not simple, and requires some user interaction. A fully automatic module signing does not make much sense, as then whatever we are trying to protect against can also make use of it (working out where VirtualBox finds the signing key is probably not a great challenge for a theoretical malware author).

Something which I have in mind is that we switch to building modules when needed when VirtualBox is started up, and asking the user for a signing key which they could point to on USB storage or on the hard drive but also providing a password. We would need to provide a similar command line interface.

I have to point out that this would be quite an investment of limited developer time resources, so nothing scheduled for the immediate future. And the user would still have to create and register a key themself. A further difficulty is telling whether signing is actually needed. On my Ubuntu system the only way I could find was looking for a message in dmesg after the first attempt to load an unsigned module (but I think that Ubuntu is doing something its own way there).

I will also point out that secure boot and module signing are actually two separate things, even if people are throwing them together. Once the kernel has booted to user-space all sorts of attacks are possible, of which loading modules is just one. As far as I know (corrections welcome), secure boot is actually mainly aimed at protecting against boot-time trojans, and once the system has loaded it has done its job. And as far as I can see, on Ubuntu at least "disabling" secure boot in the Shim does not actually disable it, it just allows loading of unsigned modules after (secure) boot. Again, if someone knows better I would love to be told.

Sorry, somewhat long answer there as this is still very unclear to me.