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.
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..
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.
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.
Also, the patch description under KB 2151132 doesn't mention this CPU vulnerability at all, only OpenSSH, libPNG and network issues.
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| Author of Vimalin. The virtual machine Backup app for VMware Desktop Products
| Vimalin : Automated backups for VMware Fusion and VMware Workstation Professional
| More info at https://www.vimalin.com
| Twitter @wilva
| VMware Wiki at http://www.vi-toolkit.com
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.
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.
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.
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
see if you have vmware update manager installed. You upload the patch there and create a "baseline" then attach that to your hosts.
Its pretty simple but you want to make sure they are in maintence mode before you do, this patch says it needs a restart.
Unfortunatly we dont have update manager installed so i would have to do it the cli way i am afraid.