[Solved] VBoxDrv.kext - kext start/stop routine failed VBoxDrv.kext - kext start/stop routine failed

Discussions related to using VirtualBox on Mac OS X hosts.

[Solved] VBoxDrv.kext - kext start/stop routine failed VBoxDrv.kext - kext start/stop routine failed

Postby TGOS » 14. Jan 2019, 17:31

Installation of Virtualbox 6 fails on 10.14.2 because the installer script cannot load the kernel extension and the reason given is
Failed to load /Library/Application Support/VirtualBox/VBoxDrv.kext - (libkern/kext) kext (kmod) start/stop routine failed.

I already tried rebooting, uninstalling the previous version and re-installing, etc. Nothing of this helped.
And when looking at the system log, I see this:
Code: Select all   Expand viewCollapse view
default   16:08:32.914765 +0100   kernel.development   AssertLogRel /Users/vbox/tinderbox/mac-rel/src/VBox/Runtime/r0drv/darwin/dbgkrnlinfo-r0drv-darwin.cpp(390) int rtR0DbgKrnlDarwinCheckStandardSymbols(RTDBGKRNLINFOINT *): <NULL>
default   16:08:32.914774 +0100   kernel.development   IOMalloc (ffffff800b8431d0 != ffffff800b7baad0)
default   16:08:32.915756 +0100   kernel.development   AssertLogRel /Users/vbox/tinderbox/mac-rel/src/VBox/Runtime/r0drv/darwin/dbgkrnlinfo-r0drv-darwin.cpp(390) int rtR0DbgKrnlDarwinCheckStandardSymbols(RTDBGKRNLINFOINT *): <NULL>
default   16:08:32.915762 +0100   kernel.development   IOMalloc (ffffff800b8431d0 != ffffff800b7baad0)
default   16:08:32.915956 +0100   kernel.development   VBoxDrv: Failed to open kernel symbols, rc=-226
default   16:08:32.915966 +0100   kernel.development   Kext org.virtualbox.kext.VBoxDrv start failed (result 0x5).
default   16:08:32.915973 +0100   kernel.development   Kext org.virtualbox.kext.VBoxDrv failed to load (0xdc008017).
default   16:08:32.915977 +0100   kernel.development   Failed to load kext org.virtualbox.kext.VBoxDrv (error 0xdc008017).

This has nothing to do with Gatekeeper permissions or SIP (System Integrity Protection) as far as I can tell. I'm developing Kernel Extensions for macOS myself, so I have some experience with that topic and on my system SIP is actually even disabled. Even incorrectly signed KEXT load fine on my system. This error clearly comes from the fact that the module start routine returns an error code instead of zero and if it was a Gatekeeper issue, the module start routine would not even get called. The error code is 5 as this call tells me:
Code: Select all   Expand viewCollapse view
> sudo kextutil -t -v 6 /Library/Application\ Support/VirtualBox/VBoxDrv.kext

Loading /Library/Application Support/VirtualBox/VBoxDrv.kext.
(kernel) User-space log flags changed from 0x0 to 0xfff.
(kernel) Received kext load request from user space.
(kernel) Received request from user space to load kext org.virtualbox.kext.VBoxDrv.
(kernel) Loading kext org.virtualbox.kext.VBoxDrv.
(kernel) Kext com.apple.kpi.libkern is already loaded.
(kernel) Kext com.apple.kpi.unsupported is already loaded.
(kernel) Kext com.apple.kpi.iokit is already loaded.
(kernel) Kext com.apple.kpi.mach is already loaded.
(kernel) Kext com.apple.kpi.bsd is already loaded.
(kernel) Allocated link buffer for kext org.virtualbox.kext.VBoxDrv at 0xffffff7f8ebff000 (978944 bytes).
(kernel) Kext org.virtualbox.kext.VBoxDrv executable loaded; 239 pages at 0xffffff7f83dff000 (load tag 206).
(kernel) Kext org.virtualbox.kext.VBoxDrv calling module start function.
(kernel) Kext org.virtualbox.kext.VBoxDrv registered class org_virtualbox_SupDrv.
(kernel) Kext org.virtualbox.kext.VBoxDrv has IOService subclass org_virtualbox_SupDrv; enabling autounload.
(kernel) Kext org.virtualbox.kext.VBoxDrv registered class org_virtualbox_SupDrvClient.
(kernel) Kext org.virtualbox.kext.VBoxDrv did not start (return code 0x5).
(kernel) Kext org.virtualbox.kext.VBoxDrv start failed (result 0x5).
(kernel) Kext org.virtualbox.kext.VBoxDrv failed to load (0xdc008017).
(kernel) Failed to load kext org.virtualbox.kext.VBoxDrv (error 0xdc008017).
(kernel) Kext org.virtualbox.kext.VBoxDrv unloading.

The important line is VBoxDrv did not start (return code 0x5).
Last edited by TGOS on 4. Apr 2019, 12:16, edited 1 time in total.
TGOS
 
Posts: 8
Joined: 14. Jan 2019, 17:04

Re: VBoxDrv.kext - kext start/stop routine failed

Postby socratis » 14. Jan 2019, 17:52

I split your post from the "Installation fails on 10.13.x, 10.14.x (rc=-1908)" thread. You may be getting an error, but it's not the -1908 one, which is due to the Gatekeeper. You get something completely different.

Any system-wide modifications you might think of? The fact that you're developing kexts tells me that you're a heavy duty user/developer, which is good! You may help the rest of us who aren't figure out what's going on... ;)

And do you have the complete installer log?
If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.
Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.
socratis
Site Moderator
 
Posts: 25287
Joined: 22. Oct 2010, 11:03
Location: Greece
Primary OS: Mac OS X other
VBox Version: PUEL
Guest OSses: Win(*>98), Linux*, OSX>10.5

Re: VBoxDrv.kext - kext start/stop routine failed

Postby TGOS » 15. Jan 2019, 12:03

Any system-wide modifications you might think of?

Well, SIP is disabled on my system (csrutil disable) so that I can load KEXTs signed with my developer ID. I have no boot args set (nvram boot-args is empty), no MDM profile installed and as far as I know never touched anything in the /System folder of macOS. Installed OS is 10.14.2 (18C54) and the hardware is a MacBook Pro Retina, Mid 2012 (2,7 GHz Core i7, 16 GB RAM). The kernel is the official one, not one of the debug or development kernels (these are not even installed on this system at the moment). I have other apps with kernel extensions and their extensions load okay, even when I delete and reinstall these apps, so it's not affecting all 3rd party extensions.

I had 5.2 installed before (don't know the exact version, might have been 5.2.20) and it prompted me that an update is available, so I downloaded 5.2.22 and this version already failed to install out of the same reason. Looking for help I went to the website and saw that 6.0 is available. Hoping that this version may fix the problem I tried 6.0 but same result. Finally I tried rolling back to 5.2.20 and 5.2.18 but neither one wants to install anymore. I cannot confirm that Virtualbox was still working at all prior to the failed update as I have probably never used it since the 10.14.2 system update (last time I used it was most likely still with 10.14.1 and there everything was working okay). But I have no way to roll my system back to 10.14.1 for testing.

And do you have the complete installer log?

Haven't saved it as it didn't seem to reveal anything useful but since I can reproduce that issue running the installer again, I can always create a new one. I just cannot post it here. I get the message: You must be a member for 1 days and have 1 posts before you can post urls. I tried to obfuscate the URLs a bit (which are all file-URLs by the way) but apparently they are still recognized as such.
TGOS
 
Posts: 8
Joined: 14. Jan 2019, 17:04

Re: VBoxDrv.kext - kext start/stop routine failed

Postby socratis » 15. Jan 2019, 13:01

TGOS wrote:but since I can reproduce that issue running the installer again, I can always create a new one

It would be best if you follow the procedure below after a reboot, and without running anything else on your Mac. The reason is that the logs are going to contain information related to the installation only, and not some random messages from Safari or Mail or something else.

  1. Download the latest release, or the latest test build, if you don't already have them.

  2. Mount the DMG from the previous step. Run "VirtualBox_Uninstall.tool". Make sure there are no error messages. If there are, please post them, exactly as they appear.

  3. Double-click the "VirtualBox.pkg" to re-install VirtualBox.

  4. Once you start the installer package, press Cmd+L to show the installer log window.

  5. Choose to "Show All Logs" from the detail level drop-down list.

  6. Before you finalize the installation, due to error or not, click "Save" on the installer log window.

  7. ZIP it and attach it to your reply.

  8. Post the output of the commands (from /Applications/Utilities/Terminal):

      ls -aled@ /
      ls -aled@ /Applications
      ls -aled@ /Applications/VirtualBox.app
      ls -aled@ /private/tmp
I'd also like to see the output of 'sudo dmesg' right after the installation failed.

TGOS wrote:I just cannot post it here
Sure you can. You can't post a link to it, which is not the desired case in any event, you should be attaching logs and pics here, locally.
Image


BTW, did you go to the Security pane of the System Preferences and allowed Oracle to install drivers (Apple TN2459)? And are you running local or are you RDPing in the Mac?
If you obfuscate any information requested, I will obfuscate my response. These are virtual UUIDs, not real ones.
Do NOT reply with the "QUOTE" button, please use the "POST REPLY", at the bottom of the form.
socratis
Site Moderator
 
Posts: 25287
Joined: 22. Oct 2010, 11:03
Location: Greece
Primary OS: Mac OS X other
VBox Version: PUEL
Guest OSses: Win(*>98), Linux*, OSX>10.5

Re: VBoxDrv.kext - kext start/stop routine failed

Postby TGOS » 15. Jan 2019, 17:03

You noticed that I'm a developer, right? You even noticed that I'm a kernel developer, didn't you? Okay, please don't make me jumps through rings for no further purpose. E.g. the output of

Code: Select all   Expand viewCollapse view
ls -aled@ /
ls -aled@ /Applications
ls -aled@ /Applications/VirtualBox.app
ls -aled@ /private/tmp

cannot be related to the problem. None of these are seen, touched or checked when I load the KEXT with kextutil. The installer is not failing because it cannot write to these directories or load anything from there, it fails because running kextload fails and running kextload fails because the start routine of the KEXT returns with exit code 5. If you don't know what this mean, please admit that, then I will hunt down the source code of this KEXT and find it out myself as everything else but looking at the source and finding out why it would return exit code 5 is nothing more than a plain waste of time and not helping me to get my Virtualbox running again, which is the only reason I am here for.

You can't post a link to it,

I wasn't trying to post a link to it. As the log is rather small, I pasted the log to the post body as code-section but as the log contains file URLs, I got this error message. The installer log is actually also useless as it will only tell you that running postinstall script did fail and it does fail because the call to kextload within that script fails, which is what I've been telling you from the very beginning but as you apparently don't believe me, I'll attache you the installer log.

BTW, did you go to the Security pane of the System Preferences and allowed Oracle to install drivers (Apple TN2459)?

A KEXT is never loaded and a KEXT start routine is never executed if you don't do that. Again, the problem is that the KEXT start routine exists with exit code 5. The error message you get from kextutil is also completely different if haven't done that already. Also I told you that the previous version of Virtualbox was running already on my system. Once you've done that for a KEXT vendor, you never have to do it for that same vendor again as this is stored persistently in the system.

Instead of asking users this question, make them run this command in Terminal (copy&paste, start with return):

Code: Select all   Expand viewCollapse view
echo "SELECT team_id,bundle_id,allowed FROM kext_policy;"  \
| sudo sqlite3 /var/db/SystemPolicyConfiguration/KextPolicy \
| grep org.virtualbox


Then you can see immediately if the user did and in my case the output is:
Code: Select all   Expand viewCollapse view
VB5E2TV963|org.virtualbox.kext.VBoxDrv|1
VB5E2TV963|org.virtualbox.kext.VBoxNetAdp|1
VB5E2TV963|org.virtualbox.kext.VBoxNetFlt|1
VB5E2TV963|org.virtualbox.kext.VBoxUSB|1

Try on your system w/o the grep to see all KEXTs you have ever authorized. Prior to authorizations a KEXT will not show up at all in the database. If it shows up in that database but the last column says 0, then it is also not allowed to load but the system will then also not show a dialog or offer you to authorize it in the system prefs. Manipulating this database is not possible if SIP is enabled, only certain system processes can do so.

Please don't get me wrong. I know to appreciate your help but it is no help if to diagnose a problem that I have already diagnosed to the point that I know the problem is the KEXT is refusing to load and exists in its start up routine with an error code. You are doubling my work and you are wasting time that way. How is that helpful for anyone? I understand that you need to do that with people who hardly know how to run an installer but as soon as you see that people send you kextutil diagnostic output, you should take your support to a much higher level as everything else look like "dance little puppy, dance and then, if I'm happy with your dancing, maybe I will help you". My first post contained more valuable information than you get from most users during a complete support case. Your answers so far contained nothing of value compared to that.
Attachments
dmesg.txt.zip
dmesg output added when installer tries to load kext
(1.75 KiB) Downloaded 17 times
virtualbox installer log.txt.zip
Installer Log
(3.23 KiB) Downloaded 15 times
TGOS
 
Posts: 8
Joined: 14. Jan 2019, 17:04

Re: VBoxDrv.kext - kext start/stop routine failed

Postby andyp73 » 15. Jan 2019, 17:34

TGOS wrote:You noticed that I'm a developer, right? You even noticed that I'm a kernel developer, didn't you? Okay, please don't make me jumps through rings for no further purpose.

You noticed that this is a user-to-user forum, right? The people that are here, helping to provide answers to users problems, are other users. Most of us have "day jobs" and all that an aggressive tone is likely to achieve is us moving on and helping other people.

As a developer of kernel extensions you will know that "5" lives in mach/kern_return.h as KERN_FAILURE which in turn is used for KMOD_RETURN_FAILURE in mach/kmod.h!

What I believe is the correct source code is src/VBox/HostDrivers/Support/darwin/SUPDrv-darwin.cpp starting at line 270. It looks like there are a bunch of reasons why KMOD_RETURN_FAILURE can get returned from that function but there should be more information from LogRel() statements in the VBox.log file for that guest.

-Andy.
My crystal ball is currently broken. If you want assistance you are going to have to give me all of the necessary information.
Please don't ask me to do your homework for you, I have more than enough of my own things to do.
andyp73
Volunteer
 
Posts: 1640
Joined: 25. May 2010, 23:48
Primary OS: Mac OS X other
VBox Version: PUEL
Guest OSses: Assorted Linux, Windows Server 2012, DOS, Windows 10, BIOS/UEFI emulation

Re: VBoxDrv.kext - kext start/stop routine failed

Postby andyp73 » 15. Jan 2019, 18:05

dmesg.txt wrote:
RTR0DbgKrnlInfoOpen: failed to find matching kernel file! rc=-226
RTR0DbgKrnlInfoOpen: '/System/Library/Kernels/kernel' -> -226
RTR0DbgKrnlInfoOpen: '/System/Library/Kernels/kernel.development' -> -102
RTR0DbgKrnlInfoOpen: '/System/Library/Kernels/kernel.debug' -> -102
RTR0DbgKrnlInfoOpen: '/mach_kernel' -> -102

Return code -102 on the last three entries in the list is VERR_FILE_NOT_FOUND so presumably your kernel file is /System/Library/Kernels/kernel. Return code -226 is VERR_INTERNAL_ERROR_2! It is generated in src/VBox/Runtime/r0drv/darwin/dbgkrnlinfo-r0drv-darwin.cpp at the end of function rtR0DbgKrnlDarwinCheckStandardSymbols(). The comment at the start of that function states:

Code: Select all   Expand viewCollapse view
* Check the symbol table against symbols we known symbols.
*
* This is done to detect whether the on disk image and the in
* memory images matches.  Mismatches could stem from user
* replacing the default kernel image on disk.


dmesg.txt wrote:
ssertLogRel /Users/vbox/tinderbox/mac-rel/src/VBox/Runtime/r0drv/darwin/dbgkrnlinfo-r0drv-darwin.cpp(390) int rtR0DbgKrnlDarwinCheckStandardSymbols(RTDBGKRNLINFOINT *): <NULL>
IOMalloc (ffffff8029e431d0 != ffffff8029dbaad0)

IOMalloc is the first kernel symbol it checks for and it isn't finding it where it expects it to be.

The reason for that is probably something specific to your machine otherwise other macOS users (me included) could well have stumbled across it.

-Andy.
My crystal ball is currently broken. If you want assistance you are going to have to give me all of the necessary information.
Please don't ask me to do your homework for you, I have more than enough of my own things to do.
andyp73
Volunteer
 
Posts: 1640
Joined: 25. May 2010, 23:48
Primary OS: Mac OS X other
VBox Version: PUEL
Guest OSses: Assorted Linux, Windows Server 2012, DOS, Windows 10, BIOS/UEFI emulation

Re: VBoxDrv.kext - kext start/stop routine failed

Postby TGOS » 18. Jan 2019, 14:23

andyp73 wrote:The people that are here, helping to provide answers to users problems, are other users.
This is no excuse for asking meaningless information from users that ask for help. Either you know what problem a user has and you can help him or you don't know it, but then you probably shouldn't reply to him as apparently you cannot help him. It's not that my initial post wouldn't have contained enough meaningful or necessary information for a reader to immediately judge if that is a known problem to him and if that is a problem that reader can help me with or not.

andyp73 wrote:Most of us have "day jobs"
So do I and making me jump through meaningless loops is killing as much of my precious time as it kills the time of anyone reading that thread because he has the same problem or because he is trying to help. How is killing time for nothing beneficial for any user or the forum as a whole and how does it help people solving problems?

andyp73 wrote:What I believe is the correct source code is src/VBox/HostDrivers/Support/darwin/SUPDrv-darwin.cpp starting at line 270.
See? THAT is helpful. The start routine most likely fails because symbols cannot be found:

Code: Select all   Expand viewCollapse view
435       }
436       else
437           LogRel(("VBoxDrv: Failed to open kernel symbols, rc=%Rrc\n", rc));
438       return rc;
439   }

And rc is probably 5 in that case.

And the reason why it cannot find the symbols is that it cannot open the kernel image, which is indeed /System/Library/Kernels/kernel. I checked the MD5 of this kernel file and it says "82d23c358106f92710dcfcc929736829". I compared that with other users having 10.14.2 installed and they all confirmed that their kernel is in same location and has exactly the same MD5. So my kernel has definitely not been modified, it is the standard 10.14.2 kernel as shipped by Apple.

The VERR_INTERNAL_ERROR_2 is probably returned because of this line:

Code: Select all   Expand viewCollapse view
AssertLogRel /Users/vbox/tinderbox/mac-rel/src/VBox/Runtime/r0drv/darwin/dbgkrnlinfo-r0drv-darwin.cpp(390) int rtR0DbgKrnlDarwinCheckStandardSymbols(RTDBGKRNLINFOINT *): <NULL>
IOMalloc (ffffff8029e431d0 != ffffff8029dbaad0)

It bitches about IOMalloc being located at address ffffff8029e431d0 and not as expected at address ffffff8029dbaad0. Note that the actual address is generated by just having the kernel kext loader resolve a named symbol (uintptr_t)&IOMalloc and thus is guaranteed to be correct. Whereas the "expected address is generated by rtR0DbgKrnlDarwinLookup which takes address of a symbol table loaded by rtR0DbgKrnlDarwinLoadSymTab and adds an offset generated by looking up the symbol "kernel_map".

I have no idea what all of this is supposed to even be good for as none of this is needed to use IOMalloc() or know its address (the first address is its address and this address is correct). The comments say "This is done to detect whether the on disk image and the in memory images matches." but I don't know why this would play a role to begin with.

I found this user to have the error message in the kernel log: viewtopic.php?f=8&t=90698

Code: Select all   Expand viewCollapse view
default   20:32:37.555435 +0000   kernel   AssertLogRel /Users/vbox/tinderbox/5.2-mac-rel/src/VBox/Runtime/r0drv/darwin/dbgkrnlinfo-r0drv-darwin.cpp(562) int rtR0DbgKrnlDarwinCheckStandardSymbols(RTDBGKRNLINFOINT *): <NULL>
default   20:32:37.555449 +0000   kernel   IOMalloc (ffffff8017a15fd0 != ffffff8017a15b90)

Also after updating from 10.14.1 to 10.14.2. Dito on this Pastebin entry: https://pastebin.com/dM5EKaam So apparently I'm not the only user where real locations of symbols don't match with expected locations.
TGOS
 
Posts: 8
Joined: 14. Jan 2019, 17:04

Re: VBoxDrv.kext - kext start/stop routine failed

Postby andyp73 » 18. Jan 2019, 14:46

TGOS wrote:And the reason why it cannot find the symbols is that it cannot open the kernel image, which is indeed /System/Library/Kernels/kernel. I checked the MD5 of this kernel file and it says "82d23c358106f92710dcfcc929736829". I compared that with other users having 10.14.2 installed and they all confirmed that their kernel is in same location and has exactly the same MD5. So my kernel has definitely not been modified, it is the standard 10.14.2 kernel as shipped by Apple.

I can also confirm that my iMAC is using the same 10.14.2 kernel with the same MD5. I have successfully run VirtualBox v5.2.22, v6.0.0, v6.0.2 and a good number of test builds in between and have never had a problem with the kexts not loading correctly. You are also the first person that I recall raising this as an issue on the forums so it may hint at there being an issue with the configuration of your system rather than a generic VirtualBox issue.

If the kernel file itself hasn't been modified and we are supposing that the address checks are failing because it can't find the symbols from the kernel file on disk, it could be a permissions issue. This is what I see:

Code: Select all   Expand viewCollapse view
$ ls -la /System/Library/Kernels/kernel
-rwxr-xr-x  1 root  wheel  15792408 13 Nov 04:28 /System/Library/Kernels/kernel


TGOS wrote:I have no idea what all of this is supposed to even be good for as none of this is needed to use IOMalloc() or know its address (the first address is its address and this address is correct). The comments say "This is done to detect whether the on disk image and the in memory images matches." but I don't know why this would play a role to begin with.

Speculating... this is probably part of the security and hardening checks to make sure that the system isn't compromised and that nothing in turn will compromise VirtualBox and the guests.

You may find that you get more answers in either the #vbox or #vbox-dev channels on Freenode IRC. Whilst I develop on an iMac I don't develop for macOS so my ability to interpret the specifics of the source files is limited.

-Andy.
My crystal ball is currently broken. If you want assistance you are going to have to give me all of the necessary information.
Please don't ask me to do your homework for you, I have more than enough of my own things to do.
andyp73
Volunteer
 
Posts: 1640
Joined: 25. May 2010, 23:48
Primary OS: Mac OS X other
VBox Version: PUEL
Guest OSses: Assorted Linux, Windows Server 2012, DOS, Windows 10, BIOS/UEFI emulation

Re: VBoxDrv.kext - kext start/stop routine failed

Postby TGOS » 18. Jan 2019, 16:04

I booted in recovery mode and re-enabled SIP (csrutil enable) but that made no difference. Then I booted to single user mode and ran fsck_apfs on the disk but I didn't find any errors. Finally I checked for kernel extensions loaded that could make a difference but the only KEXT loaded that isn't from Apple is org.pqrs.driver.Karabiner.VirtualHIDDevice.v060800 from Karabiner and it is taking control of my external keyboard and I've been using that for ages - not loading it make no difference either.

andyp73 wrote:
Code: Select all   Expand viewCollapse view
$ ls -la /System/Library/Kernels/kernel
-rwxr-xr-x  1 root  wheel  15792408 13 Nov 04:28 /System/Library/Kernels/kernel

Mine looks the same except that is one hour older (or this is caused by time zone, not sure):
Code: Select all   Expand viewCollapse view
-rwxr-xr-x  1 root  wheel  15792408 Nov 13 05:28 /System/Library/Kernels/kernel
TGOS
 
Posts: 8
Joined: 14. Jan 2019, 17:04

Re: VBoxDrv.kext - kext start/stop routine failed

Postby granada29 » 19. Jan 2019, 23:27

I can confirm identical results as @andyp73 with tz adjusted timestamp. I have had no trouble running VirtualBox 5.x.x or 6.x.x on my 2017 iMac 5K (18,3)
$ ls -la /System/Library/Kernels/kernel
-rwxr-xr-x 1 root wheel 15792408 13 Nov 17:28 /System/Library/Kernels/kernel
$ md5 /System/Library/Kernels/kernel
MD5 (/System/Library/Kernels/kernel) = 82d23c358106f92710dcfcc929736829
number9:~ bryan$
Last edited by socratis on 20. Jan 2019, 12:27, edited 1 time in total.
Reason: Enclosed the information in [quote][pre] tags for better readability
granada29
 
Posts: 77
Joined: 3. Mar 2015, 07:27

Re: VBoxDrv.kext - kext start/stop routine failed

Postby TGOS » 23. Jan 2019, 11:57

I installed the 10.14.3 update yesterday resulting in a new kernel file (MD5: 88b5308b1aa54f58b8ccfccf52b74459) but that made no difference either, it still fails to load just as it did before, still claiming that IOMalloc() is at the wrong address.

Note that the address testing stops after the first failure and IOMalloc() is the first address tested, so it's not even said that any of the other addresses would fail that test.
TGOS
 
Posts: 8
Joined: 14. Jan 2019, 17:04

Re: [Solved] VBoxDrv.kext - kext start/stop routine failed

Postby TGOS » 4. Apr 2019, 12:16

To find out which kernel has been loaded, the developers are currently doing the following:

  1. They look for possible kernel file candidate by iterating over a list of hardcoded paths and kernel file names.
  2. If such a file is found, they load the Mach-O header from the kernel file and look up and remember the memory addresses of various symbols within that kernel file.
  3. They look-up a symbol named "kernel_map" in memory and subtract its real memory address from the memory address as found in the Mach-O file loaded in (2) to obtain the offset of displacement between the memory layout for that the kernel file has been compiled and the real memory layout after it has been loaded.
  4. Finally they check if this offset is also correct for the other known symbols by taking the symbol address from (2), adding the offset from (3) and testing if that results in the real memory address of that symbol. If all symbols match, they assume the right kernel file has been found, otherwise the search continues.
All of this is only done to find out which kernel file has been loaded!
And it's a horrible poor and unfortunately also flawed way of doing it.

The reason why that is poor is simply the fact that every kernel has a unique UUID. Just run

Code: Select all   Expand viewCollapse view
otool -l /System/Library/Kernels/kernel

and look for LC_UUID.

And of course the UUID of the loaded kernel can also be accessed from within that kernel.
It even is visible to user space processes, just run

Code: Select all   Expand viewCollapse view
sysctl kern.uuid

Also instead of hardcoded file names, the code should iterate all files of the directory where kernel files are located.

The reason why this is flawed is that using kernel_map is probably the worst symbol you can use for calculating the offset as there are various reasons why the kernel will have to replace that symbol during load time and in all these cases the offset of this symbol (and only this symbol) will be different to the offset of all the other symbols. This is not a critical situation, though, if VirtualBox would just not use kernel_map for calculating the offset, everything would work correctly and as expected.

In my case the kernel_map was replaced at load time as a result of values found in certain cache files.

Here is how I could solve it:

  1. Disable System Integrity Protection (SIP)
    1. Reboot to the Recovery System by restarting your Mac and hold down the Command and R keys (⌘-R) at startup.
    2. From the Utilities menu, select Terminal
    3. Run the following command: csrutil disable
    4. Restart your Mac.
  2. Once your Mac has rebooted, open a Terminal and run the following commands to remove all caches and have macOS rebuild them on next boot:

    Code: Select all   Expand viewCollapse view
    sudo rm /System/Library/Caches/com.apple.kext.caches/Startup/kernelcache.de*
    sudo rm /System/Library/PrelinkedKernels/prelinkedkernel.de*
    sudo kextcache -invalidate /

  3. Enable SIP again. Same steps as in (1), but the command is csrutil enable
TGOS
 
Posts: 8
Joined: 14. Jan 2019, 17:04


Return to VirtualBox on Mac OS X Hosts

Who is online

Users browsing this forum: Majestic-12 [Bot] and 15 guests