Microsoft is aware of new variants of the class of attack known as speculative execution side-channel vulnerabilities. The variants are named L1 Terminal Fault (L1TF) and Microarchitectural Data Sampling (MDS). An attacker who can successfully exploit L1TF or MDS may be able to read privileged data across trust boundaries.
UPDATED ON May 14, 2019: On May 14, 2019, Intel published information about a new subclass of speculative execution side-channel vulnerabilities known as Microarchitectural Data Sampling. They have been assigned the following CVEs:
CVE-2018-11091 – “Microarchitectural Data Sampling Uncacheable Memory (MDSUM)”
CVE-2018-12126 – “Microarchitectural Store Buffer Data Sampling (MSBDS)”
CVE-2018-12127 – “Microarchitectural Fill Buffer Data Sampling (MFBDS)”
CVE-2018-12130 – “Microarchitectural Load Port Data Sampling (MLPDS)”
UPDATED ON NOVEMBER 12, 2019: On November 12, 2019, Intel published a technical advisory around Intel® Transactional Synchronization Extensions (Intel® TSX) Transaction Asynchronous Abort vulnerability that is assigned CVE-2019-11135. Microsoft has released updates to help mitigate this vulnerability. Please note the following:
By default, operating systems protections are enabled for some Windows Server OS Editions. See Microsoft Knowledge Base Article 4072698 for more information.
By default, operating systems protections are enabled for all Windows Client OS Editions. See Microsoft Knowledge Base Article 4073119 for more information.
In environments in which resources are shared, such as virtualization hosts, an attacker who can run arbitrary code on one virtual machine may be able to access information from another virtual machine or from the virtualization host itself.
Server workloads such as Windows Server Remote Desktop Services (RDS) and more dedicated roles such as Active Directory domain controllers are also at risk. Attackers who can run arbitrary code (regardless of its level of privilege) may be able to access operating system or workload secrets such as encryption keys, passwords, and other sensitive data.
Windows client operating systems are also at risk, especially if they run untrusted code, leverage Virtualization Based Security features like Windows Defender Credential Guard, or use Hyper-V to run virtual machines.
Note: These vulnerabilities affect Intel Core processors and Intel Xeon processors only.
To resolve these issues, Microsoft is working together with Intel to develop software mitigations and guidance. Software updates to help mitigate the vulnerabilities have been released. To obtain all available protections, updates may be required that could also include microcode from device OEMs.
This article describes how to mitigate the following vulnerabilities:
CVE-2018-3620 – "L1 Terminal Fault – OS, SMM"
CVE-2018-3646 – "L1 Terminal Fault – VMM"
CVE-2018-11091 – "Microarchitectural Data Sampling Uncacheable Memory (MDSUM)"
CVE-2018-12126 – "Microarchitectural Store Buffer Data Sampling (MSBDS)"
CVE-2018-12127 – "Microarchitectural Load Port Data Sampling (MLPDS)"
CVE-2018-12130 – "Microarchitectural Fill Buffer Data Sampling (MFBDS)"
CVE-2019-11135 – “Windows Kernel Information Disclosure Vulnerability”
To learn more about the vulnerabilities see the following security advisories:
Windows Kernel Information Disclosure Vulnerability: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-11135
Determining actions necessary to mitigate the threat
The following sections can help you identify systems that are affected by the L1TF and/or MDS vulnerabilities, and also help you to understand and mitigate the risks.
Potential performance impact
In testing, Microsoft has seen some performance impact from these mitigations, depending on the configuration of the system and which mitigations are required.
Some customers may have to disable hyper-threading (also known as simultaneous multithreading or SMT) to fully address the risk from L1TF and MDS. Be aware that disabling hyper-threading can cause performance degradation. This situation applies to customers who use the following:
Versions of Hyper-V that are earlier than Windows Server 2016 or Windows 10 version 1607 (Anniversary Update)
Virtualization-based security (VBS) features such as Credential Guard and Device Guard
Software that allows execution of untrusted code (for example, a build automation server or shared IIS hosting environment)
The impact can vary by hardware and the workloads that are running on the system. The most common system configuration is to have hyper-threading enabled. Therefore, the performance impact is gated on the user or administrator who is taking the action to disable hyper-threading on the system.
Note: To determine whether your system is using VBS-protected security features, follow these steps:
On the Start menu, type MSINFO32.
Note: The System Information window opens.
In the Find what box, type security.
In the right pane, locate the two rows that are selected in the screen shot, and check the Value column to see whether Virtualization-based Security is enabled and which virtualized-based security services are running.
The Hyper-V core scheduler mitigates the L1TF and MDS attack vectors against Hyper-V virtual machines while still allowing hyper-threading to remain enabled. The core scheduler is available starting with Windows Server 2016 and Windows 10 version 1607. This provides minimal performance impact to the virtual machines.
The core scheduler does not mitigate the L1TF or MDS attack vectors against VBS-protected security features. For more information, refer to Mitigation C and the following Virtualization Blog article:
For detailed information from Intel about the performance impact, go to the following Intel website:
Identifying affected systems and required mitigations
The flow chart in figure 1 can help you identify affected systems and determine the correct set of actions.
Important: If you’re using virtual machines, you must consider and apply the flow chart to Hyper-V hosts and each affected VM guest individually because mitigations may apply to both. Specifically, for a Hyper-V host, the flow chart steps provide inter-VM protections and intra-host protections. However, applying these mitigations to only the Hyper-V host is not sufficient to provide intra-VM protection. To provide intra-VM protection, you must apply the flow chart to each Windows VM. In most cases, this means making sure that the registry keys are set in the VM.
As you navigate the flow chart, you will encounter lettered blue circles that map to an action or a series of actions that are required to mitigate L1TF attack vectors that are specific to your system configurations. Each action that you encounter must be applied. When you encounter a green line, it indicates a direct path to the end, and there are no additional mitigation steps.
A short-form explanation of each lettered mitigation is included in the legend on the right. Detailed explanations for each mitigation that include step-by-step installation and configuration instructions are provided in the "Mitigations" section.
Important: The following section describes mitigations that should be applied ONLY under the specific conditions that are determined by the flow chart in Figure 1 in the previous section. Do NOT apply these mitigations unless the flowchart indicates that the specific mitigation is necessary.
In addition to software and microcode updates, manual configuration changes may also be required to enable certain protections. We further recommend that Enterprise customers register for the security notifications mailer in order to be alerted about content changes. (See Microsoft Technical Security Notifications.)
Obtain and apply the latest Windows updates
Apply all available Windows operating system updates, including the monthly Windows security updates. You can see the table of affected products on the Microsoft Security Advisory | ADV 180018 for L1TF, Security Advisory | ADV 190013 for MDS, and CVE-2019-11135 for the Windows Kernel Information Disclosure Vulnerability.
Obtain and apply the latest microcode or firmware updates
In addition to installing the latest Windows security updates, a processor microcode update is also required. Installation of these updates is provided by the device OEM.
Note: If you’re using nested virtualization (including running Hyper-V containers in a guest VM), you must expose the new microcode enlightenments to the guest VM. This might require upgrading the VM configuration to version 8. Version 8 includes the microcode enlightenments by default. For more information and the required steps, see the following article Microsoft Docs article:
Should I disable hyper-threading (HT)?
The L1TF and MDS vulnerabilities introduce risk that the confidentiality of Hyper-V virtual machines and the secrets that are maintained by Microsoft Virtualization Based Security (VBS) could be compromised by using a side-channel attack. When Hyper-Threading (HT) is enabled, the security boundaries provided by both Hyper-V and VBS are weakened.
The Hyper-V core scheduler (available starting with Windows Server 2016 and Windows 10 version 1607) mitigates the L1TF and MDS attack vectors against Hyper-V virtual machines while still allowing Hyper-Threading to remain enabled. This provides minimal performance impact.
The Hyper-V core scheduler does not mitigate the L1TF or MDS attack vectors against VBS-protected security features. The L1TF and MDS vulnerabilities introduce risk that the confidentiality of VBS secrets could be compromised via a side-channel attack when Hyper-Threading (HT) is enabled, weakening the security boundary provided by VBS. Even with this increased risk, VBS still provides valuable security benefits and mitigates a range of attacks with HT enabled. Hence, we recommend that VBS continue to be used on HT-enabled systems. Customers who want to eliminate the potential risk of the L1TF and MDS vulnerabilities on the confidentiality of VBS should consider disabling HT to mitigate this additional risk.
Customers who want to eliminate the risk that the L1TF and MDS vulnerabilities pose, whether to the confidentiality of Hyper-V versions that are earlier than Windows Server 2016 or to VBS security capabilities, must weigh the decision and consider disabling HT to mitigate the risk. In general, this decision can be based upon the following guidelines:
For Windows 10 version 1607, Windows Server 2016 and more recent systems that are not running Hyper-V and are not using VBS-protected security features, customers should not disable HT.
For Windows 10 version 1607, Windows Server 2016 and more recent systems that are running Hyper-V with the Core Scheduler, but are not using VBS-protected security features, customers should not disable HT.
For Windows 10 version 1511, Windows Server 2012 R2 and earlier systems that are running Hyper-V, customers must consider disabling HT to mitigate the risk.
The steps that are required to disable HT differ from OEM to OEM. However, they are typically part of the BIOS or firmware setup and configuration tools.
Microsoft has also introduced the ability to disable Hyper-Threading technology through a software setting if it is difficult or impossible to disable HT in your BIOS or firmware setup and configuration tools. The software setting to disable HT is secondary to your BIOS or firmware setting and is disabled by default (meaning HT will follow your BIOS or firmware setting). To learn more about this setting and how to disable HT using it, see the following article:
4072698 Windows Server guidance to protect against speculative execution side-channel vulnerabilities
When possible, it’s recommended to disable HT in your BIOS or firmware for the strongest guarantee that HT is disabled.
Note: Disabling hyperthreading will reduce the CPU cores. This can have an effect on features which require minimum CPU cores to function. For Example, Windows Defender Application Guard (WDAG).
Enable Hyper-V core scheduler and set the VM hardware thread count per core to 2
Note: These mitigation steps apply only to Windows Server 2016 and Windows 10 versions prior to version 1809. The core scheduler is enabled by default on Windows Server 2019 and Windows 10 version 1809.
Using the core scheduler is a two-stage process that requires you to first enable the scheduler on the Hyper-V host and then configure each VM to take advantage of it by setting their hardware thread count per core to two (2).
The Hyper-V core scheduler that was introduced in Windows Server 2016 and Windows 10 version 1607 is a new alternative to the classic scheduler logic. The core scheduler offers decreased performance variability for workloads inside VMs that are running on an HT-enabled Hyper-V host.
For a detailed explanation of Hyper-V’s core scheduler and the steps to enable it, see the following Windows IT Pro Center article:
Understanding and using Hyper-V hypervisor scheduler types
To enable the Hyper-V core scheduler on Windows Server 2016 or Windows 10, enter the following command:
bcdedit /set HypervisorSchedulerType core
Next, decide whether to configure a given VM’s hardware thread count per core to two (2). If you expose the fact that virtual processors are hyper-threaded to a guest virtual machine, you enable the scheduler in the VM operating system, and also the VM workloads, to use HT in their own work scheduling. To do this, enter the following PowerShell command, in which <VMName> is the name of the virtual machine:
Set-VMProcessor -VMName <VMName> -HwThreadCountPerCore 2
Enable mitigations for advisories CVE-2017-5715, CVE-2017-5754, and CVE-2019-11135
Note: These mitigations are enabled by default on Windows Server 2019 and Windows client operating systems.
To enable mitigations for advisories CVE-2017-5715, CVE-2017-5754, and CVE-2019-11135, use the guidance in the following articles:
4072698 Windows Server guidance to protect against speculative execution side-channel vulnerabilities
4073119 Windows client guidance for IT Pros to protect against speculative execution side-channel vulnerabilities
Note: These mitigations include and automatically enable the safe page frame bits mitigation for the Windows kernel and also for the mitigations that are described in CVE-2018-3620. For a detailed explanation of the safe page frame bits mitigation, see the following Security Research & Defense Blog article:
Third-party information disclaimer
The third-party products that this article discusses are manufactured by companies that are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, about the performance or reliability of these products.
Third-party contact disclaimer
Microsoft provides third-party contact information to help you find additional information about this topic. This contact information may change without notice. Microsoft does not guarantee the accuracy of third-party contact information.
Guidance for mitigating speculative execution side-channel vulnerabilities in Azure