Bugzilla – Bug 1175201
VirtualBox fails with kernel 5.8
Last modified: 2020-09-20 16:14:22 UTC
Created attachment 840578 [details] Changes needed for kernel 5.8 for patch to module_memory to work First some background: For several cycles, the kernel developers have been restricting the allocation of executable memory for out-of-kernel modules. With 5.8, the method used by VirtualBox is no longer accessible. The resulting error is as follows: Failed to open a session for the virtual machine <VM Name> "Failed to load R0 module /usr/lib/virtualbox/VMMR0.r0: SUP_IOCTL_LDR_OPEN failed (VERR_NO_EXEC_MEMORY). Failed to load VMMR0.r0 (VERR_NO_EXEC_MEMORY)." I tried to find workarounds for this problem, but the only one I found requires modifying the kernel, which the openSUSE developers would not make part of the distribution [1][2]. I expect that Oracle will likely find a solution using libvirt, but a rewrite of that magnitude is beyond my capabilities. The current solutions are as follows: 1. Remain with kernel 5.7. 2. Convert from VirtualBox to KVM.[3] The quoted web page covers the issue, and I will not discuss it further. 3. It is reported that the test builds at [4] work. Be sure to get the latest 6.1.X test build for 64-bit Linux and the Extensions. Before installing that package, use YaST to remove all the regular VB packages. When Oracle's release runs with kernel 5.8, you will need to rerun their '.run' file with the uninstall option. This option may or may not work. I had trouble with it. 4. Use a modified kernel and modify the vboxdrv kernel module. If you do not already generate a custom kernel, use YaST to install the kernel-source package. Then cd to the kernel source directory. For those of you who used YaST to get the kernel, then that is /usr/src/linux-5.8.X-Y. X and Y will depend on the version you just installed. You will also need the corresponding config file from /boot - use 'cp /boot/config-$(uname -r) ." Everyone should download the file temp_kernel.patch into the current directory. Then run the following commands: patch -p1 < temp_kernel_patch make sudo make modules_install install If you get a permissions error from the first command, you will need to use sudo for all 3 commands. Once these commands finish, reboot into the new kernel. After you reboot, use 'sudo zypper install virtualbox-host-source package' to verify that the source is installed. Then cd /usr/src/kernel-modules/virtualbox/src Download the attachment fix_vboxdrv_for_5.8.patch and run the following: sudo patch -p1 < fix_vboxdrv_for_5.8.patch sudo make sudo make install Then reboot. VirtualBox should now work. [1] https://bugzilla.suse.com/show_bug.cgi?id=1172897 [2] https://lists.opensuse.org/opensuse-kernel/2020-06/msg00002.html [3] https://joseph.zikusooka.com/?p=981#:~:text=To%20convert%20from%20VirtualBox%20to%20KVM%2C%20look%20for%20your%20VDI%20images.&text=You%20can%20now%20import%20the,'Storage%20format'%20to%20qcow2. [4]https://www.virtualbox.org/wiki/Testbuilds
Created attachment 840579 [details] Changes needed for kernel 5.8 for patch to module_memory to work
*** Bug 1174983 has been marked as a duplicate of this bug. ***
*** Bug 1172897 has been marked as a duplicate of this bug. ***
*** Bug 1174998 has been marked as a duplicate of this bug. ***
*** Bug 1175246 has been marked as a duplicate of this bug. ***
Hi Larry, attachment https://bugzilla.suse.com/attachment.cgi?id=840579 seems to be the wrong patch. Guess, you meant to combine your module memory patch with fixes_for_5.8.patch, but commented out, and enable it with this one. Finally, I grabbed your patch from https://www.virtualbox.org/attachment/ticket/19644/fixes_for_module_memory.patch and adjusted the patch target in order to be applied with -p1, all available in https://build.opensuse.org/package/show/home:frispete:kernel/virtualbox, where a patched 5.8 kernel is available as well. Let's see, how this works out, after build finished.
Hi Larry and Hans-Peter, I applied patch https://www.virtualbox.org/attachment/ticket/19644/fixes_for_module_memory.patch with running patched kernel (https://build.opensuse.org/project/show/home:Herbster0815:virtualbox). The error still exists. I went back to the dev-version of Virtualbox which runs fine (https://www.virtualbox.org/download/testcase/VirtualBox-6.1.97-139787-Linux_amd64.run)
Hi Robert, same here. Something seems to be wrong with fixes_for_5.8.patch. I have backported the kernel module changes from SVN and will see, how this works out (searching for the minimum invasive attempt).. Does VirtualBox-6.1.97 runs on an unpatched 5.8 kernel for you?
Although, my backport[1] seems to be sane semantically, it fails to run any VM with this very issue!?! [1] https://build.opensuse.org/package/show/home:frispete:kernel/virtualbox
Created attachment 840657 [details] Patch for VB module I have reloaded the second patch - it unfortunately had the same label as the first. It was really different.
Are you patching the VirtualBox files? I had to comment out the real code so that VB would build under Kernel_HEAD_standard. Just to reiterate: The fix requires patching the kernel AND the VB driver source!
Sure, Larry, but similar to Roberts experience, it fails with the VERR_NO_EXEC_MEMORY error. My current patch (backported from SVN) ought to be kernel patch agnostic, as being found here: https://build.opensuse.org/package/view_file/home:frispete:kernel/virtualbox/kernel-5.8.patch?expand=1 but in any case, your kernel patch is located here: https://build.opensuse.org/source/home:frispete:kernel/kernel-source/patches.addon.tar.bz2?rev=2194d01040736ac65791a4fbecc97b20 and activated by line 197 in: https://build.opensuse.org/package/view_file/home:frispete:kernel/kernel-source/series.conf?expand=1 So everything is in place, is being used, but fails to operate properly. Your "Patch for VB module" wouldn't apply to alloc-r0drv-linux.c, since it refers to calling __get_vm_area_caller with a 5.8.0 signature (using the additional __builtin_return_address(0) argument, but that isn't applied in fixes_for_5.8.patch https://build.opensuse.org/package/view_file/home:lwfinger:branches:Virtualization/virtualbox/fixes_for_5.8.patch?expand=1 nor somewhere else: Index: src/vboxdrv/r0drv/linux/alloc-r0drv-linux.c =================================================================== --- src.orig/vboxdrv/r0drv/linux/alloc-r0drv-linux.c +++ src/vboxdrv/r0drv/linux/alloc-r0drv-linux.c @@ -169,8 +169,8 @@ static PRTMEMHDR rtR0MemAllocExecVmArea( size_t iPage; # if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 8, 0) -// pVmArea = __get_vm_area_caller(cbAlloc, VM_ALLOC, MODULES_VADDR, MODULES_END, -// __builtin_return_address(0)); + pVmArea = __get_vm_area_caller(cbAlloc, VM_ALLOC, MODULES_VADDR, MODULES_END, + __builtin_return_address(0)); #else pVmArea = __get_vm_area(cbAlloc, VM_ALLOC, MODULES_VADDR, MODULES_END); #endif @@ -208,9 +208,9 @@ static PRTMEMHDR rtR0MemAllocExecVmArea( pVmArea->pages = papPages; # if LINUX_VERSION_CODE >= KERNEL_VERSION(5, 8, 0) unsigned long start = (unsigned long)pVmArea->addr; -// unsigned long size = get_vm_area_size(pVmArea); + unsigned long size = get_vm_area_size(pVmArea); -// if (!map_kernel_range(start, size, PAGE_KERNEL_EXEC, papPages)) + if (!map_kernel_range(start, size, PAGE_KERNEL_EXEC, papPages)) #else if (!map_vm_area(pVmArea, PAGE_KERNEL_EXEC, # if LINUX_VERSION_CODE < KERNEL_VERSION(3, 17, 0) Hence, these patches are somewhat inconsistent. Any hints appreciated.
BTW, upstream seems to have fixed the IPRT_USE_ALLOC_VM_AREA_FOR_EXEC path, that I tried to replicate with my patch.
Pete, As I stated in my solution #4, you must apply both patches. The first to the kernel source, and the second to the sources provided by the virtualbox-host-source package. The patched vboxdrv source depends on the two new exported symbols created by the kernel patch, thus before you can build the patched vboxdrv module, you must build and BOOT the patched kernel. The sources in the VirtualBox package have the critical lines in the kernel modules commented out, otherwise they would not build with an unpatched kernel. Larry
Hi Larry, I did exactly that (semantically). I've created a patched kernel (as referenced already), that exports the requested symbols: $ egrep 'map_kernel_range|get_vm_area_caller' /proc/kallsyms ffffffffa8491160 T __get_vm_area_caller ffffffffa84925f0 T unmap_kernel_range_noflush ffffffffa84929a0 T map_kernel_range_noflush ffffffffa8492b20 T map_kernel_range ffffffffa8492c80 T unmap_kernel_range ffffffffa8492d10 T get_vm_area_caller ffffffffa96055b8 r __ksymtab___get_vm_area_caller ffffffffa960cefc r __ksymtab_map_kernel_range ffffffffa9633f29 r __kstrtabns___get_vm_area_caller ffffffffa9633f29 r __kstrtabns_map_kernel_range ffffffffa9635ac5 r __kstrtab_map_kernel_range ffffffffa9635b3d r __kstrtab___get_vm_area_caller It is available here: https://build.opensuse.org/package/show/home:frispete:kernel/kernel-source Sorry to not follow your path by the letter, but you surely can imagine, that applying diffs manually everywhere isn't the real McCoy here (even, if it's temporary). Now let's turn to virtualbox. The `Patch for VB module` from above modifies `src/vboxdrv/r0drv/linux/alloc-r0drv-linux.c`. Obviously, it attempts to activate the newly exported kernel calls. Also obviously, it refers to patches applied before. You did the main adjustments for 5.8 in https://build.opensuse.org/package/view_file/Virtualization/virtualbox/fixes_for_5.8.patch?expand=1 That patch carries some pretty instructive header comments as well. 3b is the route, that this issue is all about, isn't it? But the only change to `alloc-r0dev-linux.c` is: --- VirtualBox-6.1.12.orig/src/VBox/Runtime/r0drv/linux/alloc-r0drv-linux.c +++ VirtualBox-6.1.12/src/VBox/Runtime/r0drv/linux/alloc-r0drv-linux.c @@ -38,7 +38,7 @@ #include <linux/kmemleak.h> #if (defined(RT_ARCH_AMD64) || defined(DOXYGEN_RUNNING)) && !defined(RTMEMALLOC_EXEC_HEAP) -# if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 23) +# if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 23) && LINUX_VERSION_CODE < KERNEL_VERSION(5, 8, 0) /** * Starting with 2.6.23 we can use __get_vm_area and map_vm_area to allocate * memory in the moduel range. This is preferrable to the exec heap below. while matching, what the patch said in 3b are changes similar to that found in: https://www.virtualbox.org/attachment/ticket/19644/fixes_for_module_memory.patch I couldn't locate any similar changes in Virtualization/virtualbox. Thus, `Patch for VB module` fails to apply. Did you reproduced your instructions from scratch? OTOH, `Patch for VB module` resembles pretty much, what I found in upstream vbox SVN and looks like following the 3a approach, that wouldn't require a kernel patch beforehand..
I need to clarify again as we have a "chicken and egg" problem. The fixes_for_5.8 patch at OBS describes 3 separate problems that had to be fixed to build and run VirtualBox. The problem was that if all 3 were applied, VB would fail to build under kernel 5.8 because the necessary globals were missing. Accordingly, the patch needed to handle executable module memory was commented out. You SHOULD not apply the patch from OBS as long as you install the latest version of the virtualbox-host-source package. Assuming you have a patches kernel, either one you built, or the one that Pete referenced, then you ONLY need to apply the "Patch for VB module" listed above. It only needs to uncomment the references to acquire memory. The changes in the fixes_for_5.8.patch from OBS have already been applied.
*** Bug 1175319 has been marked as a duplicate of this bug. ***
As a workaround I booted Kernel 5.7.11, but for running VirtualBox I need to build the vboxdrv using `/sbin/vboxconfig`, which requires the kernel-devel package in version 5.7.11. Does anyone know where I can get that from?
*** Bug 1175108 has been marked as a duplicate of this bug. ***
(In reply to Sebastian Wagner from comment #18) > As a workaround I booted Kernel 5.7.11, but for running VirtualBox I need to > build the vboxdrv using `/sbin/vboxconfig`, which requires the kernel-devel > package in version 5.7.11. Does anyone know where I can get that from? Use this repository for kernel with version 5.7.11 or 5.7.12: home_tiwai_kernel_5.7 | Kernel builds for branch stable (standard) | Yes | (r ) Yes | No | rpm-md cat home_tiwai_kernel_5.7.repo [home_tiwai_kernel_5.7] name=Kernel builds for branch stable (standard) enabled=1 autorefresh=0 baseurl=https://download.opensuse.org/repositories/home:/tiwai:/kernel:/5.7/standard/ type=rpm-md gpgcheck=1 gpgkey=https://download.opensuse.org/repositories/home:/tiwai:/kernel:/5.7/standard/repodata/repomd.xml.key With this repository, VirtualBox working. But not with 5.8.0 or 5.8.1. I'll wait until it fixes. Thanks.
(In reply to Ionut Nechita from comment #20) > Use this repository for kernel with version 5.7.11 or 5.7.12: > home_tiwai_kernel_5.7 | Kernel builds for branch stable > (standard) | Yes | (r ) Yes | No | rpm-md Thank you, works perfectly for me. For those who are looking for a temporary(!) workaround too: zypper ar https://download.opensuse.org/repositories/home:/tiwai:/kernel:/5.7/standard/home:tiwai:kernel:5.7.repo zypper mr -p 90 home_tiwai_kernel_5.7 zypper in --oldpackage kernel-default-5.7.12 kernel-default-devel-5.7.12 zypper al kernel-default kernel-default-devel I don't know if setting the priority and the locks are necessary. After the issue is fixed, you can do (not tested): zypper rr home_tiwai_kernel_5.7 zypper rl kernel-default kernel-default-devel
same problem under kernel 5.8.0-1-default
Just a heads up: Virtualbox 6.1.97, fetched from SVN, and built here: https://build.opensuse.org/package/show/home:frispete:kernel/virtualbox does work including USB-{2,3} support, given the extpack r140056 from https://www.virtualbox.org/wiki/Testbuilds is installed properly. No kernel patching nor driver patching necessary. Well, internally, I'm using (an unpatched) kernel 5.8.3 from stable tree. If some of you guys are using this, please give feedback. I found Klaus Espenlaub from Oracle pretty responsive in this issue. An official release will take some more time due to some other issues.
(In reply to Hans-Peter Jansen from comment #8) > Hi Robert, > > same here. Something seems to be wrong with fixes_for_5.8.patch. > > I have backported the kernel module changes from SVN and will see, how this > works out (searching for the minimum invasive attempt).. > > Does VirtualBox-6.1.97 runs on an unpatched 5.8 kernel for you? VirtualBox-6.1.97 runs fine on an unpatched 5.8.0-1-default kernel for me.
Finally, I have an "unofficial" fix that will be distributed through normal channels. I generated a new version called 6.1.13 that was derived from commit r85883 of the Oracle svn repository. Note that Oracle only uses even numbers for the last part of an official release, thus this one will never conflict with an official release. For operations with USB{2,3}, the extension pack for revision 140056 must be installed. Once Oracle releases 6.1.14, then the extension pack and VB itself will have the same revision number. Eventually, this version will appear as an update to Tumbleweed. Until that happens, you can download the binaries from https://build.opensuse.org/package/show/Virtualization/virtualbox The extension pack can be downloaded from https://www.virtualbox.org/wiki/Testbuilds Be careful about the version. Version 140124 does not work.
> ... you can download the binaries from > https://build.opensuse.org/package/show/Virtualization/virtualbox > Not being familiar with build.opensuse, which do I download?
Open that page. On the right-hand side of the screen, you will see a heading of virtualbox. Under it, click on the openSUSE_Factory link just above the x86_64. Download the following: python3-virtualbox-6.1.13-555.1.x86_64.rpm virtualbox-6.1.13-555.1.x86_64.rpm virtualbox-devel-6.1.13-555.1.x86_64.rpm virtualbox-host-source-6.1.13-555.1.noarch.rpm virtualbox-qt-6.1.13-555.1.x86_64.rpm The vnc and websrv rpms are optional. Back up one page and find the entries under virtualbox:kmp. You will need to select your version here - openSUSE_Factory for Tumbleweed. Download virtualbox-kmp-default-6.1.13_xxxxxx.x86_64.rpm for that version of openSUSE. Back at your host, use sudo zypper install ~/Downloads/virtualbox*.rpm If you downloaded somewhere other than ~/Downloads/, use that directory. If you get any problems with the kmp-default package, chose to ignore its dependencies. In addition, these packages are not signed. When zypper complains, use "i" to ignore that problem. At the moment, the kmp-default for openSUSE_Factory is built against kernel 5.8.4, but 5.8.2 is the distributed kernel. You will need to build the kernel modules by running 'sudo /sbin/vboxconfig'. If you are missing packages needed to build the modules, that script will tell you what is needed.
Did all of that, ignored the warnings. No workee. As usual this command was needed: sudo chmod 4750 /usr/lib/virtualbox/VirtualBoxVM Starting the Vbox manager: 2020-08-30T12:03:21-0700 sma-station14l systemd[4445]: Started Application launched by gnome-shell. 2020-08-30T12:03:21-0700 sma-station14l virtualbox.desktop[20641]: /usr/lib/virtualbox/VirtualBox6: symbol lookup error: /usr/lib/virtualbox/VirtualBox6: undefined symbol: _ZN17QIDialogContainer20setProgressBarHiddenEb Starting a guest from a desktop icon: 2020-08-30T12:03:36-0700 sma-station14l com.github.spheras.desktopfolder.desktop[20655]: VirtualBoxVM: supR3HardenedMainGetTrustedMain: dlopen("/usr/lib/virtualbox/VirtualBoxVM.so",) failed: /usr/lib/virtualbox/VirtualBoxVM.so: undefined symbol: _ZN20UIPerformanceMonitor28sltGuestAdditionsStateChangeEv
(In reply to Larry Finger from comment #27) > Open that page. On the right-hand side of the screen, you will see a heading > of virtualbox. Under it, click on the openSUSE_Factory link just above the > x86_64. Thank you Larry for all these instructions, very helpful and saved me a lot of time. It works, so now I can keep being productive. Thanks a lot!
(In reply to James Moe from comment #28) > Did all of that, ignored the warnings. No workee. > > As usual this command was needed: > sudo chmod 4750 /usr/lib/virtualbox/VirtualBoxVM > > Starting the Vbox manager: > 2020-08-30T12:03:21-0700 sma-station14l systemd[4445]: Started Application > launched by gnome-shell. > 2020-08-30T12:03:21-0700 sma-station14l virtualbox.desktop[20641]: > /usr/lib/virtualbox/VirtualBox6: symbol lookup error: > /usr/lib/virtualbox/VirtualBox6: undefined symbol: > _ZN17QIDialogContainer20setProgressBarHiddenEb > > Starting a guest from a desktop icon: > 2020-08-30T12:03:36-0700 sma-station14l > com.github.spheras.desktopfolder.desktop[20655]: VirtualBoxVM: > supR3HardenedMainGetTrustedMain: > dlopen("/usr/lib/virtualbox/VirtualBoxVM.so",) failed: > /usr/lib/virtualbox/VirtualBoxVM.so: undefined symbol: > _ZN20UIPerformanceMonitor28sltGuestAdditionsStateChangeEv What permissions level are you running? Check the value for PERMISSION_SECURITY in /etc/sysconfig/security. For most systems, it has "easy,local". The permissions package sets 4750 for VirtualBoxVM in /usr/share/permissions/permissions.easy. The secure and paranoid settings have 0750. As to your missing symbols, I cannot find either of them in the sources.
Version 6.1.13, which has all the fixes, was released in Tumbleweed snapshot 20200901. I am closing this issue.
Thanks, Larry, for all your work. That was one of the most adverse cycles in VB history (that I remeber). If we ever going to meet us physically, I would like to invite you to a drink (or two). Cheers, Pete
I am now on snapshot 20200901. VB definitely works (thanks!) but the version reported is "6.1.97_SUSE r85605" which results in VB guest (e.g. Vagrant) tooling to try to download guest additions in version 6.1.97. Should I open a new issue for that or should this be issue be reopend?
(In reply to Markus Zimmermann from comment #33) > I am now on snapshot 20200901. VB definitely works (thanks!) but the version > reported is "6.1.97_SUSE r85605" which results in VB guest (e.g. Vagrant) > tooling to try to download guest additions in version 6.1.97. Should I open > a new issue for that or should this be issue be reopend? It does not matter. I will ignore it either way. I'm very tired of this issue! Comment #25 told you what extension pack, and by implication, which additions to use. It will need to be downloaded manually.
For those, that are missing audio: switching to ALSA should do the trick..
(Due to a changed setting in email, I did not see your response.) > What permissions level are you running? Check the value for PERMISSION_SECURITY > in /etc/sysconfig/security. For most systems, it has "easy,local". PERMISSION_SECURITY="secure local" VB v6.1.13 installed and performs without a problem. Thank you.
As long as you are running "secure local", you need to copy all the lines in the VirtualBox section of /usr/share/permissions/permissions.easy into /etc/permissions.local. That will override the secure settings for VirtualBox. If you do not do this, then you will need to manually set the file permissions every time VBox is updated.
This is an autogenerated message for OBS integration: This bug (1175201) was mentioned in https://build.opensuse.org/request/show/834917 15.2 / virtualbox
openSUSE-SU-2020:1486-1: An update that fixes 25 vulnerabilities is now available. Category: security (moderate) Bug References: 1114605,1174075,1174159,1175201 CVE References: CVE-2020-14628,CVE-2020-14629,CVE-2020-14646,CVE-2020-14647,CVE-2020-14648,CVE-2020-14649,CVE-2020-14650,CVE-2020-14673,CVE-2020-14674,CVE-2020-14675,CVE-2020-14676,CVE-2020-14677,CVE-2020-14694,CVE-2020-14695,CVE-2020-14698,CVE-2020-14699,CVE-2020-14700,CVE-2020-14703,CVE-2020-14704,CVE-2020-14707,CVE-2020-14711,CVE-2020-14712,CVE-2020-14713,CVE-2020-14714,CVE-2020-14715 JIRA References: Sources used: openSUSE Leap 15.2 (src): virtualbox-6.1.14-lp152.2.5.1, virtualbox-kmp-6.1.14-lp152.2.5.1