Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Friday, January 12, 2018 1:55 AM
Hi,
After Windows and CPU microcode update, compatible AV (confirmed in the registry), and two required registry additions, Windows OS mitigation is still disabled. How do I force enable the patch? My guess, the mitigation is not enabled because the microcode was loaded with driver during boot (VMWare Labs driver), not by the BIOS.
Igor
HW: Haswell I7 4770K on Asus Z87 MOBO
SW: Windows 10 64-bit, 1709 (build 16299.192)
Output generated by SpeculationControl script:
PS C:\WINDOWS\system32> Get-SpeculationControlSettings
Speculation control settings for CVE-2017-5715 [branch target injection]
Hardware support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is enabled: False
Windows OS support for branch target injection mitigation is disabled by system policy: False
Windows OS support for branch target injection mitigation is disabled by absence of hardware support: False
Speculation control settings for CVE-2017-5754 [rogue data cache load]
Hardware requires kernel VA shadowing: True
Windows OS support for kernel VA shadow is present: True
Windows OS support for kernel VA shadow is enabled: True
Windows OS support for PCID performance optimization is enabled: True [not required for security]
Suggested actions
* Follow the guidance for enabling Windows Client support for speculation control mitigations described in https://support.microsoft.com/help/4073119
BTIHardwarePresent : True
BTIWindowsSupportPresent : True
BTIWindowsSupportEnabled : False
BTIDisabledBySystemPolicy : False
BTIDisabledByNoHardwareSupport : False
KVAShadowRequired : True
KVAShadowWindowsSupportPresent : True
KVAShadowWindowsSupportEnabled : True
KVAShadowPcidEnabled : True
All replies (9)
Friday, January 12, 2018 6:35 AM
Hi,
same issue on virtual server VMWare. ESXi updated but
Windows OS support for branch target injection mitigation is enabled: False
Windows OS support for branch target injection mitigation is disabled by system policy: False
Windows OS support for branch target injection mitigation is disabled by absence of hardware support: True
Any help welcome :-)
Laurent
Friday, January 12, 2018 9:34 AM
Hi,
In order to do more research, please check if you have taken following actions. Thanks for your understanding.
1. Run a supported antivirus application before you install operating system or firmware updates.
2. Both host PC and VM have applied all available Windows operating system updates, including the January 2018 Windows security updates (KB4056892 for 1709 (build 16299.192)). Please check it in Setting -> Updates & Security -> View installed update history.
3. Host PC has applied the applicable firmware update that is provided by the device manufacturer.
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].
Friday, January 12, 2018 11:40 AM
Having the exact same problem here. Also used VMWare driver to update Intel CPU microcode.
See: https://www.reddit.com/r/windows/comments/7pfc6d/powershell_spectremeltdown_check_says/
BTIHardwarePresent : True
BTIWindowsSupportPresent : True
BTIWindowsSupportEnabled : False
BTIDisabledBySystemPolicy : False
BTIDisabledByNoHardwareSupport : False
Friday, January 12, 2018 6:11 PM
I managed to enable the patch, but had to mod BIOS firmware with the latest microcode from intel for my CPU, i7-4960X on X79 ASUS Rampage IV Black Edition Mobo, Windows 10 x64 1709 16299.192
Before that I tried the VMWare driver, which gave me "hardware support for branch target injection mitigation: True", but I believe the OS loads the microcode too late for mitigation to be enabled.
Note that I did not have to add the registry keys as listed below to my machine in order to enable the patch:
Quoting from that link: "**Note **By default, this update is enabled. No customer action is required to enable the fixes. We are providing the following registry information for completeness in the event that customers want to disable the security fixes related to CVE-2017-5715 and CVE-2017-5754 for Windows clients."
Powershell output now looks like:
PS C:\Windows\System32\WindowsPowerShell\v1.0> Get-SpeculationControlSettings
Speculation control settings for CVE-2017-5715 [branch target injection]
Hardware support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is enabled: True
Speculation control settings for CVE-2017-5754 [rogue data cache load]
Hardware requires kernel VA shadowing: True
Windows OS support for kernel VA shadow is present: True
Windows OS support for kernel VA shadow is enabled: True
Windows OS support for PCID performance optimization is enabled: False [not required for security]
BTIHardwarePresent : True
BTIWindowsSupportPresent : True
BTIWindowsSupportEnabled : True
BTIDisabledBySystemPolicy : False
BTIDisabledByNoHardwareSupport : False
KVAShadowRequired : True
KVAShadowWindowsSupportPresent : True
KVAShadowWindowsSupportEnabled : True
KVAShadowPcidEnabled : False
Friday, January 12, 2018 6:18 PM
I saw the same thing.
This document describes what "disabled by system policy means": https://support.microsoft.com/en-us/help/4074629/understanding-the-output-of-get-speculationcontrolsettings-powershell
which references this document: https://support.microsoft.com/en-us/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution
I followed the instructions to change the registry and fixes are enabled now.
Friday, January 12, 2018 6:21 PM
But I believe the registry changes are not required for clients, only for servers?
Friday, January 12, 2018 7:35 PM
I agree the registry changes are for servers, but I tried them anyway.
I find interesting Microsoft didn't implement late activation of the mitigation (during boot), thus allowing for microcode to load by other means than BIOS. There is an old example of microcode load with Windows patch, from 2015 for Windows 8.1 and Windows Servers. They could have done same/similar patch design this time.
The example: https://support.microsoft.com/en-us/help/3064209/june-2015-intel-cpu-microcode-update-for-windows
Considering we are not getting any answers here, I'll try to build a BIOS firmware with new microcode.
Monday, January 15, 2018 3:51 PM
To add another observation (Windows 2012 R2): if the Hyper-V role is enabled on the server, VMWare microcode update driver successfully updates the microcode, but Get-SpeculationControlSettings still shows
BTIHardwarePresent : False
and a dump of CPUID tables indicates that the hypervisor does not pass the BTI bits to the client vms (including the root vm). After disabling Hyper-V, BTIHardwarePresent becomes True, but as mentioned above the software support is not enabled due to the microcode being updated too late in the boot process.
Tuesday, January 16, 2018 11:33 PM
Can you provide info on how you did the BIOS mod?