Now that the dust is slightly starting to settle It became clear to me that there’s an enormous amount of information and confusion out there. I have read a lot of websites in order to get a clear picture and being able to get all of my hosts and Virtual Machines patched. While not completely done yet, here’s my collection of links and some answers on questions that I see asked often. This is a live document and will be updated with notes relevant for patching. Last update 2018/01/29
Official website Meltdown and Spectre There is a good link overview at the bottom of the page there !
Frequently Asked Questions
- No significant performance degradations are known by patching VMware products
- Guest OS’s need patching too after you patched the Hypervisor, this is where the performance impacts occur. There’s talk that later patches might improve any performance slowdown you might see, but it is strongly suggested to patch now.
- The guest OS needs Virtual Hardware 9 to work, but Virtual Hardware 11 is needed to enable PCID/NVPCID and that’s a required CPU feature to reduce the performance impact from Meltdown
- Some of the patches also depend on firmware (CPU microcode) updates. If your hardware has firmware updates then apply those. If these are not available then your host OS (not guest OS) might be able to provide these updates on boot. For example the latest vSphere patch has CPU microcode updates for a number of processors.
- Someone at the forum noticed that the VCSA is not on Virtual Hardware 11 and asked if the VH should be upgraded. William was so nice to answer this question on twitter. “Investigation of VAs are still underway, once complete analysis has been provided & along w/resolution, my understanding is vHW guidance will be provided. I’d hold off unless KB explicitly instructs you to update vHW”
- For the Spectre patch to work you do need to shut down your VM and not just reboot/reset it as otherwise the VM will not see the new CPU features that have been exposed for the patch. Completely shutting down the VM and then starting it manually makes sure that the new CPU features are available.
Meltdown patch for VMware products VMware Security advisory VMSA 2018-0002
Spectre patch VMware Security advisory VMSA 2018-0004
Beware that the last update that addresses the Spectre vulnerability has been recalled! See KB 52345 for the details, quote:
Note: All the patches associated with VMSA-2018-0004 have been pulled back from the online and offline portal.
an excellent analysis about this mess and what to do now is over at the vNinja site: Guest Post:: The Curious Case of the Intel Microcode Part #2 – It Gets Better — Then Worse This has been dubbed #IntelSighting and William Lam has a patch script for this here: Automating Intel Sighting remediation using PowerCLI (Virtually Ghetto)
KB 52085 Hypervisor-Assisted Guest Mitigation for branch target injection about patching CVE-2017-5715 or Spectre.
PowerCLI validating compliance of VMSA-2018-0002 is about validating your mitigations against meltdown
v-front.de ESXi 6.5.0 patch tracker (change selection to ESXi 6.0 or ESXi 5.5 if needed)
KB 52337 VMware Performance Impact for Spectre and Meltdown (will be updated with info once the VMware performance team has finished their testing, which is not now)
VMware Desktop Update Download Links
- VMware Workstation Player 14.1.1
- VMware Workstation Pro 14.1.1
- VMware Workstation Pro 12.5.9
- VMware Fusion 10.1.1
- VMware Fusion 8.5.10
Windows x86 fix for Spectre is released KB4073291 (2018-01-27)
Microsoft has confirmed that Intel’s patches against can cause system instability and in some cases lead to data loss or corruption. See also update KB4078130 You will have to manually install from the Microsoft Update Catalog website (2018-01-29)
Key give away, you want to be on the latest kernel if you do not want to be impacted by performance issues
Commandline test for seeing if KPTI is enabled:
dmesg | grep "Kernel/User page tables isolation: enabled" && echo "patched" || echo "unpatched"
There is also a mentioning about checking the output of /proc/cpuinfo and look for “cpu_insecure” or “kaiser” but at least Red Hat did not follow those rules.
grep "cpu_insecure\|kaiser" /proc/cpuinfo && echo "patched" || echo "unpatched"
There’s also this script for verifying if your system is patched successfully: https://github.com/speed47/spectre-meltdown-checker (beware the disclaimer!)
The official way to check the state of your kernel mitigations according to Greg Kroah-Hartman is:
$ grep . /sys/devices/system/cpu/vulnerabilities/*
and that should output the patch state of your kernel like so:
1 2 3 4
Unfortunately Red Hat (and maybe others?) also did not port that option to their kernel, so it is difficult to know you are patched with Red Hat / CentOS (there are some hints like “spec_ctrl” and “ibpb_support” showing up in the /proc/cpuinfo output)
Only patches for the amd64 architecture have arrived so far.
Ubuntu 16.04 LTS kernel 4.4.0-108 is causing boot panics for a lot of users, this has been corrected in 4.4.0-109
Red Hat / CentOS
Note that the x32 branch will not get updates, you have to move to x64 if you’re still on 32 bits.
Kris posted a comment on the FreeNAS subreddit in regards to these exploits.
“Rest assured we are all just as eager for a fix as you. We are working with our FreeBSD folks now and will hopefully have a release with the fixes in the near future. One of the bugs in particular is a particularly non-trivial problem and we want to avoid any major performance penalty, so we are trying to make sure it is fixed “right”. We’ll post more updated information as we have it. Thanks!”
Broadwell and Haswell CPUs appear to have “reboot issues” (I think they mean crash issues) with the new firmware, so you might want to hold off on the microcode updates for those CPUs. See: Addressing Reboot Issues
retpoline: a software construct for preventing branch-target-injection this is a method developed by google to address Specre.