I've read up on forums, mailing lists and on The Register that there seems to be a severe hardware bug with Intel CPUs:
There are Linux patches in the works, and Microsoft will release patches during January's patch tuesday. Is ESXi vurnerable, and if so, when can we expect a patch for this? Since it's a critical issue, it will require lots of patching and planning - any heads up would be appreciated!
I agree that the choice of words is a bit confusing, but how can a guest OS patch be effective if you do not install it? That sentence implicates a lot already.
Also keep in mind that there are or will be patches for pretty much all current OS's, do you really want to postpone those patches to see if your guest OS is OK without that patch?
If you want to keep your guest OS current, you'll have to install the patches supplied by your guest OS.
If your guest OS is a legacy OS which will not get fixes then now you have uet another reason to either upgrade or if that is not possible to at least isolate that guest so it cannot be exploited by these flaws. An attacker does need local execution access in order to use these flaws.
edit: please also note that the exact wording is "For these patches to be fully functional in a guest OS additional ESXi and vCenter Server updates will be required. These updates are being given the highest priority. Please sign up to the Security-Announce mailing list to be alerted when these updates are available" so more patches to address all of this are expected to follow.
I guess where I'm coming from is that the bug is a hardware CPU issue but VMWare sits between the physical hardware and the guest OS. If the CPU presented to the guest is virtual then the guest isn't talking to a 'real' CPU so perhaps may not be affected by the hardware issue as long as the underlying host is patched. It's a big assumption for sure so we really need need a clear statement from VMWare.
I would have also assumed guest OS would be covered once hypervisor is patched but it seems to be somewhat unclear if that is the case.
My concern would be if there are any CPU performance impacts related to the patches referred to in VMSA-2018-0002 (which negates Spectre CVE-2017-5715 & CVE-2017-5753 -except 5.5 )
There is no mention or warning in the release notes.
Will forthcoming patch(es) for the other Spectre vulnerability (CVE-2017-5753 for ESXi 5.5 etc) have any impact on the hypervisor CPU performance?
If guest OS is patched e.g. Linux, MS - will this have impact on in guest vCPU performance?
These are going to be critical questions for enterprise environments..
If you have the latest ESXi 6.0 build installed, you are good, right? I installed ESXi-6.0.0-20171104001-standard not too long ago which is build 6921384. As far as I can tell from the product patches, that is the latest available bundle that can be installed.
VMware published the advisory board with two of the three CV from two (CVE-2017-5715 & CVE-2017-5753 no information for CVE-2017-5754)
refer to the VMware advisory link - VMSA-2018-0002 which addresses
Description of the vulnerability
An industry-wide issue was found in the way many modern microprocessor designs have implemented speculative execution of instructions (a commonly used performance optimization). There are three primary variants of the issue which differ in the way the speculative execution can be exploited. Variant CVE-2017-5715 triggers the speculative execution by utilizing branch target injection. It relies on the presence of a precisely-defined instruction sequence in the privileged code as well as the fact that memory accesses may cause allocation into the microprocessor's data cache even for speculatively executed instructions that never actually commit (retire). As a result, an unprivileged attacker could use this flaw to cross the syscall and guest/host boundaries and read privileged memory by conducting targeted cache side-channel attacks.
CVE-2017-5754 - No information published by VMware
Description of the vulnerability
relies on the fact that, on impacted microprocessors, during speculative execution of instruction permission faults, exception generation triggered by a faulting access is suppressed until the retirement of the whole instruction block. Researchers have called this exploit "Meltdown". Subsequent memory accesses may cause an allocation into the L1 data cache even when they reference otherwise inaccessible memory locations. As a result, an unprivileged local attacker could read privileged (kernel space) memory (including arbitrary physical memory locations on a host) by conducting targeted cache side-channel attacks.
They have not provided any information on legacy VMware version prior to 5.1, pretty sure they are also affected. Let's stay tuned for their forthcoming release.
Can I inquire what you came across that vmware is working on a patch for ESXi 5.5 for CVE-2017-5753?
I have been trying searching around trying to confirm this so I can plan my updates.
So, as far as I understand - in order to protect info from leaking between VMs, all that is needes is the patch ESXi600-201711101-SG for ESXi 6.0, and ESXi650-201712101-SG for ESXi 6.5?
Of course, guests need to be patched in order to protect the guest VM memory.
Am I correct?
Do the BIOS of the VMs need to be patched too? I see Microsoft have written an article about it: Protecting guest virtual machines from CVE-2017-5715 (branch target injection) | Microsoft Docs
I'm using the SpeculationControl powershell script, PowerShell Gallery | SpeculationControl 1.0.1, and it reports all green when running in Windows bare metal. When I run it on a VM running on ESXi with the same kind of hardware and firmware versions it fails the hardware support check. So it seems like something is missing?
Have anyone gotten an all green with SpeculationControl inside a VM on ESXi?
Same problem here, not possible to get it all green...
If someone has a solution...
I applied the guest OS patch & registry settings from MS.
ESXi host has been patched and BIOS upgraded to latest HP version (correcting this bug).
Already tried with VM reboot, VM shutdown,...
Always the same result:
Speculation control settings for CVE-2017-5715 [branch target injection]
Hardware support for branch target injection mitigation is present: False
Windows OS support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is enabled: False
Windows OS support for branch target injection mitigation is disabled by system policy: False
Windows OS support for branch target injection mitigation is disabled by absence of hardware support: True
Speculation control settings for CVE-2017-5754 [rogue data cache load]
Hardware requires kernel VA shadowing: True
Windows OS support for kernel VA shadow is present: True
Windows OS support for kernel VA shadow is enabled: True
Windows OS support for PCID performance optimization is enabled: False [not required for security]
* Install BIOS/firmware update provided by your device OEM that enables hardware support for the branch target injectio
BTIHardwarePresent : False
BTIWindowsSupportPresent : True
BTIWindowsSupportEnabled : False
BTIDisabledBySystemPolicy : False
BTIDisabledByNoHardwareSupport : True
KVAShadowRequired : True
KVAShadowWindowsSupportPresent : True
KVAShadowWindowsSupportEnabled : True
KVAShadowPcidEnabled : False
New patches for vSphere 5.5 / 6.0 and 6.5 have just landed. This also includes the microcode updates this time.
there is a new KB Article online, describing the "Hypervisor-Assisted Guest Mitigation for branch target injection".
There also are some more KBs regarding the Issue.
As far as I have heard so far, the performance hit is in the fixes at the guest OS level, not so much in the hypervisor level fixes.
No idea about performance implications on firmware fixes as intel isn't very communicative on what they did.
edit: see also VMSA-2018-0004 and in particular:
To remediate CVE-2017-5715 in the Guest OS the following VMware and third party requirements must be met:
- Deploy the updated version of vCenter Server listed in the table (if vCenter Server is used).
- Deploy the ESXi patches and/or the new versions for Workstation or Fusion listed in the table.
- Ensure that your VMs are using Hardware Version 9 or higher. For best performance, Hardware Version 11 or higher is recommended. VMware Knowledge Base article 1010675 discusses Hardware Versions.
Please read the entire article, but the highlighted part is at least about performance