Protecting guest virtual machines from CVE-2017-5715 (branch target injection)

This page provides additional detail about protecting virtual machines on Hyper-V hosts from CVE-2017-5715 (branch target injection). For general Windows Server guidance, please refer to this page.

The following steps are required to ensure that your virtual machines are protected:

1. Update the host operating system.
2. Ensure the virtualization host has been updated to firmware which contains updates for CVE-2017-5715.
3. Ensure Hyper-V is configured to expose new processor capabilities to guest virtual machines.
4. Update the guest operating system as required.
5. Perform a cold boot of guest virtual machines.

Update the host operating system

Apply the Windows operating system update to the virtualization host. For details about how to enable this update, see Microsoft Knowledge Base article 4072699.

Ensure the virtualization host has been updated to firmware which contains updates for CVE-2017-5715

Firmware updates from your OEM may contain new processor capabilities that can be used to protect against CVE-2017-5715 (IBRS, STIBP, IBPB). Once the virtualization host's firmware has been updated, the hypervisor can make these additional capabilities available to guest virtual machines after taking the following steps.

Ensure Hyper-V is configured to expose new processor capabilities to guest virtual machines

Ensure that Hyper-V is configured to expose the new processor capabilities into guest virtual machines. This configuration is based on the VM version of the guest virtual machines.

If all of the virtual machines on the host are VM version 8.0 or higher, then no configuration is required. These virtual machines will see the new processor capabilities after a cold boot.

If there are any virtual machines with VM version below 8.0, you must set a specific registry value on the host operating system. This will configure Hyper-V to expose the new processor capabilities into guest virtual machines with lower VM versions.

That registry value is MinVmVersionForCpuBasedMitigations under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization. The value should be set to the minimum VM version that needs access to the updated firmware capabilities, in the format “Major.Minor”. To expose the firmware to all virtual machines on the host (i.e. version 1.0 and above), run the following command on the host:

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization" /v MinVmVersionForCpuBasedMitigations /t REG_SZ /d "1.0" /f

VM Version 8.0 was introduced with Windows Server 2016 and the Windows 10 Anniversary Update. Hosts running Windows Server 2012 R2 and below must set the registry value*

Live migration will fail between hosts with the updated firmware and hosts without the updated firmware. The start operation will fail from the saved state. For more details, see the FAQ at the bottom of this article.

Optional: Configure pre-Skylake Intel systems to use Retpoline

Configuring VMs on pre-Skylake Intel hosts for Retpoline will block live migration to newer hosts (i.e. Skylake and beyond).

By default, virtual machines running on pre-Skylake systems are prevented from using retpoline. To allow these systems to leverage retpoline based mitigations, set RetsPredictedFromRsbOnly under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization to 1.

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization" /v RetsPredictedFromRsbOnly /t REG_DWORD /d 1 /f

To reverse this configuration (i.e. prevent virtual machines from leveraging retpoline), set RetsPredictedFromRsbOnly to 0.

Update the guest operating system

To complete protection against CVE-2017-5715 within these virtual machines, the guest operating system must be updated and configured to take advantage of these new capabilities. For Microsoft operating systems, please follow the guidance in this article when updating.

Note: updating the guest operating system can occur at any time in this process. It can occur before updating the host firmware or after cold booting the guest virtual machine.

Perform a cold boot of the guest

After completing the first three steps, virtual machines must go through a cold boot to see the new processor capabilities. This means the running VMs must completely power off before starting again. Rebooting from inside the guest operating system is not sufficient.

FAQ

How does this impact live migration?

Live migration of a virtual machine with the new processor capabilities will fail when moving to Hyper-V hosts without updated firmware. To enable live migration to a host without updated firmware, stop exposing the updated processor capabilities within that guest virtual machine. The easiest way to do this is to modify MinVmVersionForCpuBasedMitigations to a VM version above that of the virtual machine that needs to migrate, and perform a cold boot of that virtual machine.

Migration of virtual machines without the new processor capabilities will succeed when moving to Hyper-V hosts with updated firmware. However, a cold boot is required for these guests to see the updated firmware capabilities.

Virtual machines configured to use Retpoline on pre-Skylake Intel systems will fail to migrate to newer processor families (i.e. Skylake and newer).

What about live migration of version 5.0 virtual machines between Windows Server 2012R2 and Windows Server 2016?

To ensure success in this scenario, the registry value must set on both the Windows Server 2012R2 system and the Windows Server 2016 system. After migrating onto Windows Server 2016, the VM version will remain 5.0, and thus the registry key is required to expose the new processor capabilities to the virtual machine.

Does this guidance apply to virtual machines running on VMWare?

No, this guidance is specific to virtual machines running on Hyper-V hosts.

Does this guidance apply to Hyper-V on Windows 10?

Yes, the same steps apply for virtual machines running on both Windows Server and Client.

Do I need to install the firmware updates before performing a cold boot of the virtual machines?

Yes, you need to update the host operating system and firmware before cold booting your virtual machines.

What can I do if my OEM does not yet provide an updated firmware?

Please check out the Alternative protections for Windows Server 2016 Hyper-V Hosts against the speculative execution side-channel vulnerabilities

How do I check the VM version for my virtual machines?

Run the following PowerShell on the Hyper-V host:

Get-VM * | Format-Table Name, Version  

Do I need to do something different to protect virtual machines running under "Processor Compatibility Mode"?

No. After following the instructions on this page, the new processor capabilities will also be exposed to virtual machines started in processor compatibility mode.

What if only half of the machines in my cluster have received a firmware update?

This will impact live migration within your cluster. Virtual machines with the new processor capabilities will not be able to live migrate to hosts without the firmware update.

How can I validate that the guest virtual machine has access to the new processor features?

Use the "speculation control" PowerShell module/script. See this page for detailed instructions.

How does this impact the start operation on a VM with save state?

The start operation will fail. The easiest way to do this is to modify MinVmVersionForCpuBasedMitigations to a VM version above that of the virtual machine that needs to migrate, and perform a cold boot of that virtual machine.