Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adds kext whitelisting for VMware Tools from Fusion 11.5.3 (#45) #56

Merged
merged 1 commit into from
Apr 21, 2020

Conversation

Footpad
Copy link
Contributor

@Footpad Footpad commented Apr 20, 2020

This adds the kernel extension approval to the KextPolicy that is necessary for VMware Tools to load, a new requirement for Catalina. The new configuration may (or may not) be specific to the VMware Tools bundled with Fusion 11.5.3 (currently the latest), which was the version that was installed and approved in order to observe these values.

NB: At some point while researching this issue I found "the origin of macinbox" and found that it too also had these declarations in the KextPolicy. Observe that the values for boot_uuid and flags are different than in this diff.

For consideration

My goal for this change was to have something that worked, and there's a few things that I didn't take into consideration originally that perhaps should be. Feel free to iterate on the PR, which I'm mostly intending as a vehicle to share this configuration and the learnings I found.

  1. I swapped the order of the VMware Tools installation and setting the KextPolicy, just in case the installation of the Tools would not successfully complete unless the KextPolicy already permitted it. I did not test whether or not the ordering matters.
  2. This change includes the created_at and last_seen values for my manual installation of the Tools. While I would be surprised if these values had any unintended consequences for various use cases, in that case it might be good to get them from the system clock (or the clock of the VM, if that's known by this point).
  3. The KextPolicy SQLite3 database seems to undergo at least one migration on first boot, which adds another column cd_hash (a code signature fingerprint, which is computed at migration time) to the kext_load_history_v3 table, along with some other metadata about the migration(s). I wasn't able to figure out the macOS version compatibility story for the migration(s), so I avoided incorporating those changes here. I also figure that since the cd_hash should be different for each version of the kexts, not including it here should add some future-proofness (although I cannot speak to the other values).
  4. I explicitly didn't change the note about VMware Tools/Catalina support in the README.md, since I'm not entirely sure how to advertise version support. I wasn't super comfortable communicating anything other than explicit support for this Fusion version.

Testing

Created a Fusion VM using this change, and was able to successfully get the IP address of the VM (vmrun -T fusion getGuestIPAddress) which does not work unless the VMware Tools are installed).

@bacongravy
Copy link
Owner

Thank you so much for this PR. Regarding your points for consideration:

  1. I don't think the order matters. So I don't see any need to swap it back, either. I'll leave it the way you have it in your PR.
  2. I don't think the content of the dates matter. If we find out that they do matter in a future release then we can fix it then.
  3. I think it was a good move to avoid trying to synthesize those other columns. My general approach is to do the least amount that accomplishes the goal. (Although to be fair, this approach is why the values for the kext_load_history_v3 table got dropped when prepare_vmdk.sh was re-written; I tried removing them, and the kexts still loaded properly in every release prior to Catalina. And I didn't think to add them back when I was trying to get this to work again in Catalina, because I had convinced myself that they weren't necessary.)
  4. I'll update the README to say what is working with the latest version. I don't have the resources to maintain a test matrix for every possible combination of host and guest components, so this whole project is best effort. The following text appears early in the README: "The following software is required. Versions other than those mentioned may work, but these are the latest versions tested." My first goal is to clearly document what combination of components does work. If other combinations work, that's great too, but folks are on their own.

@bacongravy bacongravy merged commit e48a861 into bacongravy:master Apr 21, 2020
@Footpad
Copy link
Contributor Author

Footpad commented Apr 22, 2020

Awesome, thanks for accepting the PR and releasing it so quickly!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants