Intel CPU bug - VMware fix on the way?

[acederlund]

I've read up on forums, mailing lists and on The Register that there seems to be a severe hardware bug with Intel CPUs:

'Kernel memory leaking' Intel processor design flaw forces Linux, Windows redesign • The Register

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!

[ITaaP]

I've been looking into this as well, but haven't seen anything specifically for ESXi. Scary part is there can be up to a 30% performance hit after the update is applied.

[acederlund]

Yeah, that's one of the scary things - except the possible security issues, of course.. Hope that we'll hear something as soon as the embargo is lifted..

[Trymon]

In this case I have also a question.

Would it be enough in this case to patch the Hypervisor or has also every VM to be patched?
I assume it's enough to patch the Hypervisor. If not the Cloud Service providers won't be able to patch their systems.

The performance impact will be a real struggle. Have here some high IO VMs and the performance impact has the most impact if high IO is present.

[SteveR123]

Hi, did you get a definite response on this ? I'm assuming patching will be required at both hypervisor and guest kernels but would like some confirmation is possible.

Thanks

Steve

[amitpatel001]

Hi

Just wanted to know is it fairly easy to patch the hypervisor, i am currently on version 3620759 so not familier in patching esx hosts.

Any pointers on patching really appreciated.

[sjesse]

see if you have vmware update manager installed. You upload the patch there and create a "baseline" then attach that to your hosts.

vSphere Update Manager Documentation

Its pretty simple but you want to make sure they are in maintence mode before you do, this patch says it needs a restart.

[amitpatel001]

Unfortunatly we dont have update manager installed so i would have to do it the cli way i am afraid.

[daphnissov]

amitpatel001​, if you need help patching then open a new thread and folks can assist you. But if you're currently on build 3620759 of ESXi 6.0, then you have more pressing security and stability concerns as you're more than a year-and-a-half outdated on patches.

[amitpatel001]

Apologies i will do that. Sorry for problems caused.

Many Thanks

[nponeccop]

amitpatel001 On HP servers you need to update using the HP ESXi ISO (to update HP-specific drivers as well) and then apply the vmware patch.

If you didn't use custom iso to install ESXi and don't have non-standard drivers to update, you only need to apply the vmware patch.

To apply the patch you need

1) go to https://esxi-patches.v-front.de/ and read the instructions on how to turn on ssh and login

2) choose your ESXi version at the top

3) click the imageprofile link of the latest patch there - a small popup window will open

4) paste the commands from there into the ssh

5) Reboot the server

6) If ESXi crashes use Ctrl-R during boot to rollback

You only need the latest patch, they are cumulative

[sjesse]

The ticket I opened just reiterated what the security bulletin said, and said they have no more information to provide. If your on 5.5 from what I'm reading CVE-2017-5753 is not fixed but CVE-2017-5715  is

[Kosch]

Would be helpful if they had clarified if you needed to install the guest workaround patches too.

https://support.microsoft.com/en-gb/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution-s

https://support.microsoft.com/en-gb/help/4073119/windows-client-guidance-for-it-pros-to-protect-against-speculative-exe

[wila]

Hi,

Yes you also need to update your guest OS's as well.

VMSA-2018-0002 - VMware Security & Compliance Blog - VMware Blogs

--

Wil

[ijwood]

Hi Wil

That's not quite what the blog entry says though.

It's saying that for the guest vendor OS patch to be effective, you will also have to install the VMWare patch. It doesn't say how effective just installing the VMWare patch by itself will be.

[wila]

Hi,

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.

A Simple Explanation of the Differences Between Meltdown and Spectre

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.

--

Wil

[ijwood]

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.

[VCPShane]

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..

[ITaaP]

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.

[DeepakNegi420]

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

CVE-2017-5715 - Addressed & CVE-2017-5753 - Not addressed

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.

[knuter]

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?

[npiron]

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]

Suggested actions

* Install BIOS/firmware update provided by your device OEM that enables hardware support for the branch target injectio

n mitigation.

BTIHardwarePresent             : False

BTIWindowsSupportPresent       : True

BTIWindowsSupportEnabled       : False

BTIDisabledBySystemPolicy      : False

BTIDisabledByNoHardwareSupport : True

KVAShadowRequired              : True

KVAShadowWindowsSupportPresent : True

KVAShadowWindowsSupportEnabled : True

KVAShadowPcidEnabled           : False

[Wahnsinicka]

we have exact the same Problem and no Idea.

see:

spectre and meltdown patch verification...

[knuter]

Seems like an EVC update is needed? Which is not out yet... William Lam on Twitter: "Few new updates - * See https://t.co/9zZU2OP1D1 for VMware Appliances for #Spectre #Meltdown …

[daphnissov]

VMSA-2018-0002

[DeepakNegi420]

VMware has not released any fix at this point. Whilst we wait for VMware to release a patch,  few consideration in planning even patching the linux and windows servers. Obviously, Analyzing the current cluster utilization would be the key to ensure that adequate capacity is available to meet the new demand of 8% to 29% overhead. Also there is a possibility of increased overhead of memory in VMhost if Inter-Virtual Machine Transparent Page Sharing is enabled in VMhosts. It's disabled by default after 5.5 update 2 but check with VMware if you have this enabled.

Regards,

Deepak Negi

[JakubD]

The ESXi 6.0 link from the advisory ( VMware Knowledge Base ) points to patch released back in November - this doesn't seem to be right.

[wila]

Hi,

This bug was kept under NDA so that all the big players could work on it, it was AMD's patch that leaked it. See: Massive security hole in Xeons incoming? - AnandTech Forums

So it is only logical that there is no mention about the problem in the readme on what it fixes as that could possibly leak the issue at hand and would take time away for other players to fix it.

For ex. macOS 10.13.2 released early December has at least some mitigation against it.

and for Linux there was a big patch set on December 4th for exactly this problem, there might have been other patches earlier on, but this is one I found x86/mm: Use/Fix PCID to optimize user/kernel switches · torvalds/linux@6fd166a · GitHub

What I'm trying to say is that it might have been known in November too.

edit: yes this was also known in November, see GitHub - IAIK/KAISER: Kernel Address Isolation to have Side-channels Efficiently Removed  The paper it refers to might have been published before that time. It was presented at a symposium in July.

--

Wil

[sjesse]

I think wila is right, the security bulletin refers to   CVE-2017-5753, CVE-2017-5715 and most people other OS vendors are as well for this issue.

[colinsmith]

I really wonder why so many are so concerned if they think of the issue.

IF two threads hit one core in a hyperthreaded CPU at the same time

IF one is a hacked thread

IF no context switches happen

IF the hacked thread can dump the L1 cache data

IF that date contains useful data and is transfered

IF it's accessed and makes it through all other security measures and firewalls

IF it's decoded

IF it's useful

THEN it's a problem

Lot's of IF's and random happenings

So ESXi has can stop scheduling for hyperthreads

It's doesn't schedule for hyperthreading  (in the best/worst case situation that's maybe a 30% decrease in performance)

My guess is they'll code for selective hyperthreading, IF a VM is multicored then it'll let it hypertheard and let the OS deal, But not let cross VM hyperthreading unless Intel fixes the microcode.

[Dave_the_Wave]

Older CPUs that Intel has no intention of addressing microcodes, do they take any performance hit on patched VIBs?

Can late builds of ESXi have its patches "disabled"?

I'd rather let backups protect everything, and leave ESXi running without bandaids.

[JakubD]

Also, the patch description under KB 2151132 doesn't mention this CPU vulnerability at all, only OpenSSH, libPNG and network issues.

[MartyG]

VMSA-2018-0002

https://www.vmware.com/us/security/advisories/VMSA-2018-0002.html

[btesrail]

If patch both on hypervisor and guest OS, we may have double loss on performance of CPU.

Assume if run on hypervisors, only patch on hypervisor level.

BR,

Eric

[VCPShane]

My understanding is that VMware are working on a patch for ESXi 5.5 for CVE-2017-5753

[dlarocca]

Hi VCPShane,

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.

Thanks!

Dan

[sjesse]

I would open the ticket and ask them directly.

[AlanFok]

I have a ticket opened in VM asking about VMSA-2018-0002.  VMware support didn't answer in details and apparently it's the only fix.  Also according to https://blogs.vmware.com/security/2018/01/vmsa-2018-0002.html, it's also required to update vCenter to latest patch.  Mine is one version older which I doubted if it's really "necessary". 

[acederlund]

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?

[wila]

New patches for vSphere 5.5 / 6.0 and 6.5 have just landed. This also includes the microcode updates this time.

https://esxi-patches.v-front.de/ESXi-6.5.0.html

--

Wil

[BenediktFrenzel]

Hi all,

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.

- VMware Response to Speculative Execution security issues, CVE-2017-5753, CVE-2017-5715, CVE-2017-5754 (aka Spectre and Meltdown)

- VMware Virtual Appliances and CVE-2017-5753, CVE-2017-5715 (Spectre), CVE-2017-5754 (Meltdown)

Cheers,

Benedikt

[HendersonD]

Is there a performance hit once these patches are applied?

[wila]

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:

   

VMware Requirements

• 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

--

Wil

[ITaaP]

I am still not clear on patching of the guest OS. Is this required in order in order to mitigate the vulnerabilities?

[kenthhjerpe]

As far as I can understand you also need to patch the Guest OS :

VMSA-2018-0004

VMware Requirements

• 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.

Third party Requirements

• Deploy the Guest OS patches for CVE-2017-5715. These patches are to be obtained from your OS vendor.
• Update the CPU microcode. Additional microcode is needed for your CPU to be able to expose the new MSRs that are used by the patched Guest OS. This microcode should be available from your hardware platform vendor.
  VMware is providing several versions of the required microcode from INTEL and AMD through ESXi patches listed in the table. See VMware Knowledge Base 52085 for more details.

[Masch73]

And what about VM version of appliances such VCSA, PSC etc? My VCSA 6.0 U3d is VM version 8. It needs upgrade too? VMware requires - Ensure that your VMs are using Hardware Version 9 or higher. For best performance, Hardware Version 11 or higher is recommended....

[wila]

Hi,

Yes that sounds very likely, but it is a good question.

I've asked lamw​ on twitter what his thoughts on this are.

--

Wil

[wila]

Hi,

William answered as follows:

"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"

William Lam on Twitter: "@wilva Investigation of VAs are still underway, once complete analysis has been provided & alon…

--

Wil

[BenediktFrenzel]

"Hypervisor-Specific Mitigation

Mitigates leakage from the hypervisor or guest VMs into a malicious guest VM. VMware’s hypervisor products are affected by the known examples of variant 1 and variant 2 vulnerabilities and do require the associated mitigations. Known examples of variant 3 do not affect VMware hypervisor products.

VMware hypervisors do not require the new speculative-execution control mechanism to achieve this class of mitigation and therefore these types of updates can be installed on any currently supported processor. No significant performance degradation is expected for VMware’s hypervisor-specific mitigations."

- VMware Knowledge Base - VMware Virtual Appliances and CVE-2017-5753, CVE-2017-5715 (Spectre), CVE-2017-5754 (Meltdown) (52264)

but as wila said, you may want to read the full articles.

- Benedikt

[acederlund]

I'd argue that in order to solve the issue that one VM can read data from another VM, the VMware patches should be sufficient.

In order to solve memory leaks within a virtual machine, you would need to patch the Guest OS (if there is any patches available, if not, you're screwed).

[ITaaP]

Well, I am glad the latest update from VMware addresses the CPU microcode. So far I am not seeing updated BIOS releases from Supermicro.

[ITaaP]

VMware says to use at least Virtual Hardware Version 9. Well, what about VCSA? That is only running version 8. Can we safely upgrade VCSA and PSC?

[wila]

Hi ITaaP,

Please see my answer to Masch73, it is currently not recommended to change the virtual hardware on any of VMware's appliances.

--

Wil

[ITaaP]

I guess with older servers running 5.0 or 5.1 that can't be upgraded, the only option is to replace the hardware? I realize those versions of ESXi are no longer supported.

[wila]

Hi ITaaP,

Most likely yes. Replacing the hardware is the only way forward in that case.

--

Wil

[AtosMatt]

I hoping someone can answer this question, can a Virtual Machine that is not patched (legacy OS) still access data from a Virtual Machine that is fully patched? If so, do we need to start separating vulnerable VM's from protected VM's?

[dalo]

No, not if you already patched your ESXi and VC.

[wila]

Hi AtosMatt,

By what means do you mean "can it still access data" ?

If you mean via normal guest OS network sharing then I do not see why it would not be able to do so.

--

Wil

[Kosch]

Would appear that HP BL460c Gen 7 servers do not have a BIOS update but apparently are not vulnerable according to HP.

Matrix  - HPE | Side Channel Analysis Method

Patched ESX 6 with Windows 2012 R2, Hotfix and registry keys enabled. Seems to hint I need a BIOS update but HP say I dont need one.

[JoeGasper]

We found that you could have everything patched and still not be all green with SpeculationControl.

Per this KB, the order of patching/microcode is important, as we seem to have encountered.

https://kb.vmware.com/s/article/52085

We patched hosts, then VC.  Still had absence of hardware support = true.

Reboot of the hosts (all in the cluster, as stated), and after a VM reboot, SpeculationControl was all green.

[AtosMatt]

I mean can a non-patched Virtual Machine still potentially read the kernel memory of other Virtual Machines that have received the January Meltdown/Spectre patches?

[dalo]

AtosMatt​ as I told you: If you patch your VC and all ESXi you should be save, according to the known info.

Patching the OS is needed for mitigation inside the VM process to process.

[larsupilami]

I am also working on this issue and try to secure the vSphere installations.

During this process I noticed that it looks like not all CPUs get microcode updates through the vmware patches mentioned in: https://kb.vmware.com/s/article/52085

https://kb.vmware.com/s/article/52206

I applied these updates to old HPE servers (DL380p Gen 7 and Gen 8) with X5650 or E5-2640 CPUs (launched in 2012 or even before). With the result that there was no Hypervisor-Assisted Guest Mitigation. I check this with the script provided by Wiliam Lam: https://www.virtuallyghetto.com/2018/01/verify-hypervisor-assisted-guest-mitigation-spectre-patches-using-powercli.html

and the Microsoft way with the SpeculationControl script inside the Guest OS (with vSphere Hardware Version >9 and after a cold boot of the system): Speculation Control Validation PowerShell Script

Of course I followed the described update procedure very close. And tried all tricks I could imagine or find on the web (reboot esx host, power off the esx host and boot it again, change Cluster EVC, remove the host from EVC cluster, and even reinstalling the host from scratch).

So it looks like the vmware patch is not updating the microcode on all Intel CPUS. This would also fit to the Intel statement that they will bring microcode updates for processors of the last 5 years within this week. But I could find a list of processors Intel already provided CPU microcode updates.

To double check the finding I installed the updates (with the exact same procedure) on another platform with Lenovo blades using E5-2660 v4. This systems also has no CPU microcode/Bios updates available so far like the HPE systems.

But here everything is fine. I got Hypervisor-Assisted Guest Mitigation enabled and verified by both scripts mentioned above just by installing the lastest vSphere updates as described in https://kb.vmware.com/s/article/52085

So it would be really interesting to know which CPUs models microcode is really updated by the vmware patch.

If there is something I am missing or if there is a trick I am missing I am glad to get this information.

[pbraren]

VMware has also published a helpful overview article 52245, explaining, and linking to many other KB articles for various VMware products. Lasted updated on 1/12/2018:

VMware Response to Speculative Execution security issues, CVE-2017-5753, CVE-2017-5715, CVE-2017-5754 (aka Spectre and Meltdown) (52245)

https://kb.vmware.com/s/article/52245

Excerpts:

Introduction

On January 3, 2018, it became public that CPU data cache timing can be abused by software to efficiently leak information out of mis-speculated CPU execution, leading to (at worst) arbitrary virtual memory read vulnerabilities across local security boundaries in various contexts. Three variants have been recently discovered by Google Project Zero and other security researchers; these can affect many modern processors, including certain processors by Intel, AMD and ARM:

• Variant 1: bounds check bypass (CVE-2017-5753) – a.k.a. Spectre
• Variant 2: branch target injection (CVE-2017-5715) – a.k.a. Spectre
• Variant 3: rogue data cache load (CVE-2017-5754) – a.k.a. Meltdown

Operating systems (OS), virtual machines, virtual appliances, hypervisors, server firmware, and CPU microcode must all be patched or upgraded for effective mitigation of these known variants.

VMware hypervisors do not require the new speculative-execution control mechanism to achieve this class of mitigation and therefore these types of updates can be installed on any currently supported processor. No significant performance degradation is expected for VMware’s hypervisor-specific mitigations.

[JakubD]

And now VMware has recalled the latest patches, because of issues with microcode upgrades:

https://kb.vmware.com/s/article/52345

[acederlund]

Read that as well, need to know a couple of things from VMware:

* What happens if we don't do the workaround? I haven't seen anything about what problems this can cause.

* Is another workaround to install microcode/BIOS from server provider, or are their updates faulty as well?

Can anyone from VMware please enlighten us?

[dalo]

according to Intel the issues are "higher system reboots":

Intel Security Issue Update: Addressing Reboot Issues

[acederlund]

Ah, yes. That makes it so much clearer. Wonder what the "higher system reboots" acually means.

Will the host spontaneously reboot, or will it PSOD?

[larsupilami]

The issue is not related to the hosts.

It is related to the guest OS. So you could see higher Guest OS reboots. What ever a reboot is.

In addition I wanted to share the following article:

The Curious Case of the Intel Microcode Part #2 - It Gets Better — Then Worse - vNinja.net

Good article and some details about the status of current CPU microcode updates. For all people with older CPUs:

No Sandy Bridge or older microcode updates so far. So be patient if you are still using such CPUs.

[acederlund]

The issue is not related to the hosts.

It is related to the guest OS. So you could see higher Guest OS reboots. What ever a reboot is.

I'd love to see some confirmation or information from VMware about this, would make the scope of mitigation much more clear, and how we should prioritize stuff in day to day operations.

This whole issue has been a mess, anyone who just sat still and didn't patch did the right choice so far..

[Petter_Lindgren]

We've already deployed the patches. Thankfully, our servers don't have the affected CPU's (Broadwell and Haswell).

What a huge mess!

[larsupilami]

For those who installed the now removed vmware patches make sure to check

https://www.virtuallyghetto.com/2018/01/automating-intel-sighting-remediation-using-powercli-ssh-not-required.html

A very nice and esay to handle way of disabling the faulty microcode update for your guest VMs.

Unfortunately had to use it for one cluster. But thanks to William Lam and his great script this was very easy to handle.

[nponeccop]

Just to clarify, they removed all January patches for ESXi, not only the latest one with microcode. Fortunately I decided to wait and didn't install them.

As for "more frequent reboots" I updated my laptop BIOS and now Windows has "more frequent BSODs". But from what other people said here, I understand that for ESXi it means guest crashes, the host is not affected.

[VCPShane]

'removed all January patches', I know they have stated this in relation to VMSA-2018-0004.

Is there an official statement for the other advisories VMSA-2018-0002?

[larsupilami]

Out of https://kb.vmware.com/s/article/52345 that provides the information about the faulty update it says:

For ESXi hosts that have not yet applied one of the following patches ESXi650-201801402-BG, ESXi600-201801402-BG, or ESXi550-201801401-BG, VMware recommends not doing so at this time. It is recommended to apply the patches listed in VMSA-2018-0002instead.

[nponeccop]

Yes, there are official statements in the same link: VMware Knowledge Base

For ESXi hosts that have not yet applied one of the following patches ESXi650-201801402-BG, ESXi600-201801402-BG, or ESXi550-201801401-BG, VMware recommends not doing so at this time. It is recommended to apply the patches listed in VMSA-2018-0002 instead.

For servers using unaffected processors which have applied either the VMSA-2018-0002 or ESXi patches ESXi650-201801402-BG, ESXi600-201801402-BG or, ESXi550-201801401-BG, no action is required.

[VCPShane]

Thanks, I guess that means that CVE-2017-5753 is not addressed yet for ESXi 5.5\6\6.5 then.