Ubantu 22.04.2 on Dell XPS intel 12th gen, secure boot enabled. VM networking not working.

[Chrisswh]

Hello, I'm running a fresh install of Ubantu LTS 22.04.2 on Dell XPS intel 12th gen, secure boot enabled.

First step to getting VMware WS pro 17 to work, Sign the vmmon module:

Sign the vmmon module:

A. Generate a signing key by running the following command:

openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -nodes -days 36500 -subj "/CN=My Name/"

This will create two files MOK.priv and MOK.der.

B. Sign the vmmon module by running the following command:

sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 ./MOK.priv ./MOK.der $(modinfo -n vmmon)

C. Register the key with Secure Boot by running the following command:

sudo mokutil --import MOK.der

reboot, re-enroll.

Secure Boot self-sign complete.

-------

Now my vmware VMs can boot up however networking still isn't working, no virtual adapters are showing up.

things I've tried:

sudo nmcli networking on

sudo apt-get update

sudo apt-get install build-essential linux-headers-$(uname -r)

sudo apt-get install gcc make

sudo vmware-installer -u vmware-workstation

sudo vmware-installer -i vmware-workstation

sudo nmcli networking on

NOTE* when running > sudo vmware-modconfig --console --install-all ----> (This command will rebuild and install all VMware kernel modules,

including the network adapter module.)

Starting VMware services:

Virtual machine monitor                                 failed

Virtual machine communication interface                     done

VM communication interface socket family                  done

Virtual ethernet                                              failed

VMware Authentication Daemon                                  done

Unable to start services

It seems like VMware is unable to start up certain services pertaining to its networking functionality.

This should be an easy endeavor, im on a clean install of ubantu LTS 22.04.2 and officially supported Dell hardware, this should be almost plug and play what am i getting wrong here? can someone please help me....

when running this command it gives me the following output in at the end of its execution.

its possible i have to sign additional modules, so for i've only signed vmmon, its possible the network adapter has its own module that needs to be signed if thats the case please let me know how to go about that step by step, it took 3 lines of code to get vmmon signed and running, its possible i have to concatenate the other modules to the original secure boot self sign. Unfortunately disabling secure boot in not an option, i need this running with secure boot enabled.

[bluefirestorm · Accepted solution]

Both vmmon and vmnet has to be signed.
The "virtual machine monitor" is the vmmon and "Virtual ethernet" is vmnet.
Rebuilding will require re-signing and re-enrolling of the keys as the rebuilt vmmon and vmnet modules lost their signatures (that's why in your post you see virtual machine monitor failed to start as well).

Longer term, maintenance of the certificates stored in the TPM needs to be done (using mokutil --delete <whatever>.DER) as it will run out of space to store them. Will probably vary by TPM chip vendor but the amount of space isn't that big. Older certificates while valid for 36500 days as specified in the openssl command line are of no use anymore. The vmmon and vmnet module versions that were signed with them no longer exists with the rebuilt modules as the Linux kernel gets updated.

[Chrisswh]

its working! Thank you so much its been a really frustrating morning. To those having facing the same issue its 5 easy steps:

First install vmware player/workstation pro

then open terminal:

openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -nodes -days 36500 -subj "/CN=My Name/"

sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 ./MOK.priv ./MOK.der $(modinfo -n vmmon)

sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 ./MOK.priv ./MOK.der $(modinfo -n vmnet)

sudo mokutil --import MOK.der

now reboot and re-enroll your key.

[Chrisswh]

Just to clarify on the TPM maintenance, for the vmware certificates i used sudo mokutil --import MOK.der which I'm guessing means MOK.der is where the certificates are stored for vmware on the TPM, next time there's a kernel update and i need to update my certificates again i can just do sudo mokutil --delete MOK.der to remove them and redo the cert signing process to get vmware back up and running right? There no risk of me getting locked out of my desktop because deleted the ubantu keys right? MOK.der in this instance is strictly for vmware kernel modules right?

kind regards,

Christopher

[bluefirestorm]

I don't have a full grasp of the technicals of those command lines (just being monkey-see monkey-do with KB2146460); but I operate under the assumption that these are to prevent from the kernel modules being tampered with and the certificates are used as a form of trust. Another assumption is that the .der would contain the signature (probably the SHA256 hash) of the two newly built binaries.

So my assumption could very well be wrong...

With that in mind, here is what I do for my own system.

I place a suffix of the uname -r

sudo openssl req -new -x509 -newkey rsa:2048 -keyout VMware16-$(uname -r).priv -outform DER -out VMware16-$(uname -r).der -nodes -days 365 -subj "/CN=VMware/"

sudo /usr/src/linux-headers-`uname -r`/scripts/sign-file sha256 ./VMware16-$(uname -r).priv ./VMware16-$(uname -r).der $(modinfo -n vmmon)

sudo /usr/src/linux-headers-`uname -r`/scripts/sign-file sha256 ./VMware16-$(uname -r).priv ./VMware16-$(uname -r).der $(modinfo -n vmnet)

sudo mokutil --import VMware16-$(uname -r).der

So the easiest way to manage this without having the certificates accumulate in the TPM is once a new .der is enrolled and it works fine, the previous one can then be deleted.

For example, the previous kernel version

mokutil --delete VMware-16-5.19.0-40-generic.der
reboot to delete certificate

You don't have to necessarily follow this method as this works for me as an individual and not an enterprise with dozens or even thousands of PCs/laptops to manage. It might be different also for an enterprise rollout as the .priv and .der probably shouldn't be readily accessible by any ordinary user nor stored on the local storage of the PC/laptop for security reasons as it is probably like leaving the keys to the main door of a house on the doormat.

You can also list the .der with mokutil --export. And it will create a list of MOK0001.der through MOK00??.der however many is stored in the TPM. But then you have to figure out which correct MOK00??.der to delete/remove from the TPM.

[Chrisswh]

This is perfect, I'm going to implement this for my own system. Thank you for your time, hopefully this will help others as well.