Vmware Hyperthreading Unmitigated
A host that is enabled for hyperthreading should behave similarly to a host without hyperthreading. You might need to consider certain factors if you enable hyperthreading, however.
Because VMware guests do not know about the underlying hyper -threading topology of the host, this is the only option that can prevent concurrent -context speculative side-channel attacks within a VM. This option has the highest security and lowest performance. L1TF related “esx.problem.hyperthreading.unmitigated” vCenter Server Updates: CVE-2018-3646 (57374) Symptoms After applying the ESXi patches in VMSA-2018-0020 or patches from later releases, vCenter Server displays one of these L1 Terminal Fault related notifications.
ESXi hosts manage processor time intelligently to guarantee that load is spread smoothly across processor cores in the system. Logical processors on the same core have consecutive CPU numbers, so that CPUs 0 and 1 are on the first core together, CPUs 2 and 3 are on the second core, and so on. Virtual machines are preferentially scheduled on two different cores rather than on two logical processors on the same core.
If there is no work for a logical processor, it is put into a halted state, which frees its execution resources and allows the virtual machine running on the other logical processor on the same core to use the full execution resources of the core. The VMware scheduler properly accounts for this halt time, and charges a virtual machine running with the full resources of a core more than a virtual machine running on a half core. This approach to processor management ensures that the server does not violate any of the standard ESXi resource allocation rules.
Consider your resource management needs before you enable CPU affinity on hosts using hyperthreading. For example, if you bind a high priority virtual machine to CPU 0 and another high priority virtual machine to CPU 1, the two virtual machines have to share the same physical core. In this case, it can be impossible to meet the resource demands of these virtual machines. Ensure that any custom affinity settings make sense for a hyperthreaded system.
This article documents the Hypervisor-Specific Mitigations required to address CVE-2018-3646 (L1 Terminal Fault - VMM) in vSphere.The Update History
section of this article will be revised if there is a significant change. Click Subscribe to Article in the Actions box to be alerted when new information is added to this document and sign up at our Security-Announce mailing list to receive new and updated VMware Security Advisories.Introduction to CVE-2018-3646
Intel has disclosed details on a new class of CPU speculative-execution vulnerabilities known collectively as “L1 Terminal Fault” that can occur on past and current Intel processors (from at least 2009 – 2018) [See Table 1 for supported vSphere processors that are affected].
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
- Sequential-context attack vector: a malicious VM can potentially infer recently accessed L1 data of a previous context (hypervisor thread or other VM thread) on either logical processor of a processor core.
- Concurrent-context attack vector: a malicious VM can potentially infer recently accessed L1 data of a concurrently executing context (hypervisor thread or other VM thread) on the other logical processor of the hyperthreading-enabled processor core.
Vmware Hyperthreading Unmitigated Usb
Mitigation Summary
Vmware Kb Esx.problem.hyperthreading.unmitigated
- Mitigation of the Sequential-Context attack vector is achieved by vSphere updates and patches. This mitigation is enabled by default and does not impose a significant performance impact. Please see resolution section for details.
- Mitigation of the Concurrent-context attack vector requires enablement of a new feature known as the ESXi Side-Channel-Aware Scheduler. The initial version of this feature will only schedule the hypervisor and VMs on one logical processor of an Intel Hyperthreading-enabled core. This feature may impose a non-trivial performance impact and is not enabled by default. Please see resolution section for details.
Vmware Hyperthreading Unmitigated Meaning
Unlike explicit disabling of Intel Hyperthreading in firmware/BIOS (or by using MKernel.Boot.Hyperthreading), the side channel aware scheduler enablement will be ignored on AMD processors and newer Intel processors that are not vulnerable to L1TF-VMM. [See Table 1 for supported vSphere processors that are affected].