Reading Time: 6 minutes

Meltdown and Spectre are critical vulnerabilities existing in several modern CPU: these hardware bugs allow programs to steal data which is currently processed on the computer. Meltdown and Spectre can affect personal computers, mobile devices, server and several cloud services.

Actually, the only way to minimize those security risks is to patch your operating systems, but also the hypervisor level and the hardware level (if vendors provide a new firmware).

For VMware, I’ve already described the security issues and how to patch your vSphere environment:

  • You have to first apply the right patches to the ESXi part, VUM can assist you properly by applying all critical (and not critical with the attention of micro-code) patches.
  • Then you have also to fix your virtual appliances, like PSC and vCenter Server with the latest update, in this case, VAMI is your best friend. But don’t reboot your VMs, you have to shutdown them and then power on again.
  • Finally, you have to patch your VM (as documented in VMSA-2018-0004), ensure that virtual hardware 9 (better is 11 or later) is used and again power off and power on your VM.

If you have Intel Haswell and Broadwell processors, be sure to verify your CPU according to with VMware KB 52345 before applying VMware’s initial microcode patches ESXi650-201801402-BG, ESXi600-201801402-BG, or ESXi550-201801401-BG.

Check your vSphere environment

Willian Lam has released a nice PowerCLI script to check your vSphere environment. Note the on January 15, he has added a second script adding also the remediation of the hosts!

The following information is related to the first version of the script, new scripts are more than one, so just refer to this blog page.

The PowerCLI script is called VerifyESXiMicrocodePatch.ps1 and it contains the following two functions:

  • Verify-ESXiMicrocodePatchAndVM
  • Verify-ESXiMicrocodePatch

I’ve verified the script using some vSphere 6.5 environments and a Windows Server 2016 as a client for PowerCLI, and it works really well. If you have some nested ESXi (in my case I’ve tested also a VSAN 6.6 stretched cluster with the virtual appliance for the witness), it shows the details of the virtual ESXi (and in the new script, the details of the physical CPU). I’ve not tested yet on some whitebox to see if it works.

You can download the script from GitHub and then simply import it:

Import-Module .\VerifyESXiMicrocodePatch.ps1

At this point you first have to ensure a connection with an ESXi host or, better, the vCenter Server:

Connect-VIServer vcenter1.lab.local

Now you can check your hosts with the Verify-ESXiMicrocodePatch command. For example to check all ESXi hosts with the name starting with “esxi”:

PS C:\Users\amauro\Desktop> Verify-ESXiMicrocodePatch -VMHostName esxi*

VMHost          IBRPresent IBPBPresent STIBPresent Affected
——          ———- ———– ———– ——–
esxi1.lab.local True       True        True        False
esxi2.lab.local True       True        True        False
esxi3.lab.local True       True        True        False

All host must show Affect=False if they are correctly patched! For ESXi 6.5 the new build will be 7526125 and the most recent VIBs are:

esxcli software vib list | grep 2018

cpu-microcode 6.5.0-1.38.7526125 VMware VMwareCertified 2018-01-10

esx-base 6.5.0-1.38.7526125 VMware VMwareCertified 2018-01-10
esx-tboot 6.5.0-1.38.7526125 VMware VMwareCertified 2018-01-10

For the microcode, if you have Intel Haswell and Broadwell processors, be sure to verify your CPU according to VMware KB 52345. Note that this script does not verify (yet) if the CPU accepts the VMware’s microcode or not. You have to manually check the KB and your processors. The script has been updated on 13 January to handle also this check.

Now you can check your VM to verify if they are using the hypervisor assisted protection.

For example to check all the machine “veeamproxy#”:

PS C:\Users\amauro\Desktop> Verify-ESXiMicrocodePatchAndVM -VMName veeamproxy?

VM           IBRPresent IBPBPresent STIBPresent vHW    Affected
—           ———- ———– ———– —    ——–
veeamproxy1  True       True        True        vmx-11 False
veeamproxy2  True       True        True        vmx-11 False

Again, all the VMs must show Affect=False if the protection at hypervisor level is working!

Note that this script shows also the virtual hardware in order to verify it (virtual hardware should be equal or greater than 9).

VMs have to powered off and then powered on again after you have applied all ESXi patches, otherwise, the protection will not work. The protection is working if, in the vmware.log file of each VM you can find following entries:

  • “Capability Found: cpuid.IBRS”
  • “Capability Found: cpuid.IBPB”
  • “Capabliity Found: cpuid.STIBP”

Note if you are using EVC: in order to maintain this compatibility, the new features are hidden from guests within the cluster until all hosts in the cluster are properly updated.  At that time, the cluster will automatically upgrade its capabilities to expose the new features.

Note that this script does not check VMware’s virtual appliances version and patch level. This must be performed manually.

There are also other tools to make those checks. For example, Runecast analyzer v1.6.6 can help with Meltodwn and Spectre detection and patching.

Check your VM guest environment

You have complete the VMware part, but not the VM guest part. For VMware’s virtual appliance there are some patches, for affected VM. In vSphere 6.5 the new build of vCenter Server (and PSC) will be 7515524.

For other virtual appliance, you must check your vendor.

For Microsoft Windows guest OS you can use again PowerShell and a specific modules called SpeculationControl.

In Windows Server 2016, you have to install the module (with Administrator privileges):

Install-Module SpeculationControl

Then you need to import it:

Import-Module SpeculationControl

On Windows Server 2012 R2 (or previous version) you have to manually download it from, uncompress the folder and manually import with the location of the SpeculationControl.psd1 file.

Finally, you can check your protection level:


Remember that for Windows Server OS you have to activate part of the kernel patches. In this example Windows it’s updated, but the kernel patches are not activated in the registry (or via Group Policy):

For Linux, you can use the powerful shell script spectre-meltdown-checker available on GitHub. You can download it with this command:

And then just run it to check your status. For example for a not patched OS:

Note that it works on mainly Linux distributions, but with Photon OS (used for example in VCSA 6.5) doesn’t report the path correctly for all the voices: