Hide esx.problem.hyperthreading.unmitigated message
I have done all the patches, but I have not disabled hyperthreading. I have waited and listened. One person I know and trust has found that now when he buys three servers, he has to buy four. And that is due to disable of HypterThreading, and all the security patches we have been hit with. I cannot easily buy additional servers so I am not going to disable hypterthreading so I need to get rid of that darn message.
We need to work in Advanced System Settings on each host.
So type uservars into the filter bar, and than scroll down a bit and you will see the parameter – as you see above.
Then use the Edit button, and filter again and scroll again.
You can see above that I have changed the 0 to 1 which is the surpress value. Hit OK, and refresh the browser.
And the message is gone.
Now we know how to fix this message manually, I was going to do it via PowerShell. So much easier and do it to all the hosts in the cluster at the same time. However, I won’t be doing that right now. I have one server that doesn’t see any datastores right now. The host suggests the 10 GiB card is not working. But I think it is. So will wrestle with that, then figure out PowerShell, and add it to below. Sorry about the delay.
What is esx.problem.hyperthreading.unmitigated?
Like Meltdown, Rogue System Register Read, and “Lazy FP state restore”, the “L1 Terminal Fault” vulnerability can occur when affected Intel microprocessors speculate beyond an unpermitted data access. By continuing the speculation in these cases, the affected Intel microprocessors expose a new side-channel for attack. (Note, however, that architectural correctness is still provided as the speculative operations will be later nullified at instruction retirement.)
CVE-2018-3646 is one of these Intel microprocessor vulnerabilities and impacts hypervisors. It may allow a malicious VM running on a given CPU core to effectively infer contents of the hypervisor’s or another VM’s privileged information residing at the same time in the same core’s L1 Data cache. Because current Intel processors share the physically-addressed L1 Data Cache across both logical processors of a Hyperthreading (HT) enabled core, indiscriminate simultaneous scheduling of software threads on both logical processors creates the potential for further information leakage. CVE-2018-3646 has two currently known attack vectors which will be referred to here as “Sequential-Context” and “Concurrent-Context.” Both attack vectors must be addressed to mitigate CVE-2018-3646..
Attack Vector Summary
Mitigation Summary
So that’s what the warning was about. To enable the ESXi Side Channel Aware scheduler we need to set the key above to “true”. More excerpts:
The Concurrent-context attack vector is mitigated through enablement of the ESXi Side-Channel-Aware Scheduler which is included in the updates and patches listed in VMSA-2018-0020. This scheduler is not enabled by default. Enablement of this scheduler may impose a non-trivial performance impact on applications running in a vSphere environment. The goal of the Planning Phase is to understand if your current environment has sufficient CPU capacity to enable the scheduler without operational impact.
The following list summarizes potential problem areas after enabling the ESXi Side-Channel-Aware Scheduler:
Note: It may be necessary to acquire additional hardware, or rebalance existing workloads, before enablement of the ESXi Side-Channel-Aware Scheduler. Organizations can choose not to enable the ESXi Side-Channel-Aware Scheduler after performing a risk assessment and accepting the risk posed by the Concurrent-context attack vector. This is NOT RECOMMENDED and VMware cannot make this decision on behalf of an organization.
So to fix the second issue we need to enable the new scheduler. That can have a performance hit, so best to enable it manually so you are aware and can keep an eye on the load and performance hits. Also, if you are not in a shared environment and don’t care, you don’t need to enable it either. Makes sense.
That warning message could have been a bit more verbose though! 🙂