Windows 10 Update Mitigates Spectre Related Performance Slowdown

AlphaAtlas

[H]ard|Gawd
Staff member
Joined
Mar 3, 2018
Messages
1,713
A big Linux release over the weekend added the "Retpoline" Spectre mitigation to the Linux kernel, but BleepingComputer reports that Windows got the same treatment. Google shared the Retpoline software mitigation technique last year, shortly after they publicly revealed Spectre and Meltdown, which Microsoft says "works by replacing all indirect call or jumps in kernel-mode binaries with an indirect branch sequence that has safe speculation behavior." Microsoft claims the update that brings the mitigations is enabled by default in Windows Insider Fast Builds, but if you want to verify the Spectre protection status yourself, they posted a fairly straightforward Powershell tutorial. In a nutshell, just download the SpeculationControl module from a link in the guide, unzip it, open a powershell console via the start menu, and copy the commands into the console. Note that I couldn't get the script working without changing "Import-Module.SpeculationControl.psd1" to "Import-Module SpeculationControl.psd1".

Retpoline has significantly improved the performance of the Spectre variant 2 mitigations on Windows. When all relevant kernel-mode binaries are compiled with retpoline, we've measured ~25% speedup in Office app launch times and up to 1.5-2x improved throughput in the Diskspd (storage) and NTttcp (networking) benchmarks on Broadwell CPUs in our lab. It is enabled by default in the latest Windows Client Insider Fast builds (for builds 18272 and higher on machines exposing compatible speculation control capabilities) and is targeted to ship with 19H1.


EDIT: I tried to automate the Spectre checking tool with a BAT file, but it in short, it has to be done manually :/
 
Last edited:
^ So? It also suggest that the new mitigation code is in alpha development. I wonder if it will help with any of my workstation needs (eventually) at work. Home computer is Ryzen, so I need all kinds of different updates to Windows for that. :)
 
I guess "Spectre slowdown mitigation" is one positive way to characterize the latest round of BSODs.
 
So you need to update to the Alpha branch of Windows 10 to get this. Classy... :/

So you propose they what? Just release the code with no testing?

Come on man, that is some silly MS-hate. The proper way to do things is to develop them, then put them through extensive testing. That's what they are doing. It is new, so it is in alpha testing. As it gets more tested it'll be moved downstream to eventual mainline release.
 
They go back to actually having an internal QA department? Instead of running Alpha/Beta code on public clients that pay money for their software? This isn't news. Go look at the October 1809 build fiasco...

So you propose they what? Just release the code with no testing?

Come on man, that is some silly MS-hate. The proper way to do things is to develop them, then put them through extensive testing. That's what they are doing. It is new, so it is in alpha testing. As it gets more tested it'll be moved downstream to eventual mainline release.
 
"Note that I couldn't get the script working without changing Import-Module.\SpeculationControl.psd1" to "Import-Module SpeculationControl.psd1

Looks like you are missing a space. Should be "Import-Module .\SpeculationControl.psd1"

Just Tab it out. -> import-module .\S <press tab> it will fill it out for you. Be more specific if you have other scripts in the same folder .\Spec <tab> etc.
 
They go back to actually having an internal QA department? Instead of running Alpha/Beta code on public clients that pay money for their software? This isn't news. Go look at the October 1809 build fiasco...

They do, they have software test engineers, a position that pays quite well (6 figures). However they also release test versions of software to the public so you can do your own testing, prior to release. This is useful to help find bugs because, I hate to break it to you, but no matter how much testing you do internally there's just way too many configurations in the world to test everything. It is also useful to organizations so they can test what is coming down the pipe and be ready for it.

But no, surely only MS is the only organization that releases test builds for people to try. I mean it isn't like FreeBSD has multiple releases... oh wait, it does. There's a Production branch, which is what is used for mainstream productions systems, a Stable branch that is in development but has been fairly tested, despite still being in development and a Current branch which is the bleeding edge development and has the least testing. Ok well that's surely an anomaly, nobody who does commercial software would do that. It isn't like Juniper Networks has multiple releases of Junos... oh wait, they do too! For any given platform there's a recommended Junos release which is the one that is most tested, stable, and supported for that platform and will continue to have engineering support for a long time. However you can get other newer (and older) releases too, each quarter there's a new Junos release and you can run them, but they aren't as tested, and there could be some issues. Finally you can opt in to getting development releases if you want to test bleeding edge stuff, though you have to contact them and convince them they should give you access.

Come on, give it a rest. It is not only common, but a good idea to have test code available to the public to test, if they want. Any sort of FOSS is going to do that, and many commercial organizations do the same. It doesn't mean they do no testing, if that were the case the release branch would be the same as the dev branch. It just means you can test it as well, if you wish.
 
They do, they have software test engineers, a position that pays quite well (6 figures). However they also release test versions of software to the public so you can do your own testing, prior to release. This is useful to help find bugs because, I hate to break it to you, but no matter how much testing you do internally there's just way too many configurations in the world to test everything. It is also useful to organizations so they can test what is coming down the pipe and be ready for it.

But no, surely only MS is the only organization that releases test builds for people to try. I mean it isn't like FreeBSD has multiple releases... oh wait, it does. There's a Production branch, which is what is used for mainstream productions systems, a Stable branch that is in development but has been fairly tested, despite still being in development and a Current branch which is the bleeding edge development and has the least testing. Ok well that's surely an anomaly, nobody who does commercial software would do that. It isn't like Juniper Networks has multiple releases of Junos... oh wait, they do too! For any given platform there's a recommended Junos release which is the one that is most tested, stable, and supported for that platform and will continue to have engineering support for a long time. However you can get other newer (and older) releases too, each quarter there's a new Junos release and you can run them, but they aren't as tested, and there could be some issues. Finally you can opt in to getting development releases if you want to test bleeding edge stuff, though you have to contact them and convince them they should give you access.

Come on, give it a rest. It is not only common, but a good idea to have test code available to the public to test, if they want. Any sort of FOSS is going to do that, and many commercial organizations do the same. It doesn't mean they do no testing, if that were the case the release branch would be the same as the dev branch. It just means you can test it as well, if you wish.
Yeah I mean my accounting system that runs RHEL only requires that I run specified hardware on specific firmware/bios configurations made by specific vendors right down to the hard drives that are installed on the machine otherwise in invalidate any warranties and it only costs some $100,000 every year in licensing.

Yeah I have at least 2 win 10 machines in every site running the insider builds just so I have a few guinea pigs on each site, they know who they are and they get a few perks along with it, like being able to bypass the ticketing system and call support directly if they have an issue. The alternatives are waiting weeks or months for validation testing for half the software we use to make sure nothing is broken with an update. Granted it has been years since we have seen a windows update break a software set but we have seen it break older GP policies and other things that really mess up a persons work flow.
 
I installed this update for Windows 10 (17763.348) and I see no issues, then again RETPoline (or whatever it's called) isn't enabled on my system with my 8700K. I have no idea why though.
 
I installed this update for Windows 10 (17763.348) and I see no issues, then again RETPoline (or whatever it's called) isn't enabled on my system with my 8700K. I have no idea why though.

From:
Windows 10 Update KB4482887 Released With Performance Fix for Spectre Bug

Retpoline is not applicable to Skylake and later processors from Intel."

Also
Retpoline mitigations have been tested using Windows 10 Insider builds since build 18272 and with this update have now been backported to Build 1809. The fixes will not be enabled immediately, but will be done so over the next few months in order to make sure new issues do not pop up when utilized publicly.

"Over the coming months, we will enable Retpoline as part of phased rollout via cloud configuration. Due to the complexity of the implementation and changes involved, we are only enabling Retpoline performance benefits for Windows 10, version 1809 and later releases."


Here's my output when running the powershell command with my i7 4790k and Microsoft Windows [Version 10.0.17763.348]:
PS C:\WINDOWS\system32> Get-SpeculationControlSettings
For more information about the output below, please refer to https://support.microsoft.com/en-in/help/4074629

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: True [not required for security]

Speculation control settings for CVE-2018-3639 [speculative store bypass]

Hardware is vulnerable to speculative store bypass: True
Hardware support for speculative store bypass disable is present: True
Windows OS support for speculative store bypass disable is present: True
Windows OS support for speculative store bypass disable is enabled system-wide: False

Speculation control settings for CVE-2018-3620 [L1 terminal fault]

Hardware is vulnerable to L1 terminal fault: True
Windows OS support for L1 terminal fault mitigation is present: True
Windows OS support for L1 terminal fault mitigation is enabled: True


BTIHardwarePresent : True
BTIWindowsSupportPresent : True
BTIWindowsSupportEnabled : True
BTIDisabledBySystemPolicy : False
BTIDisabledByNoHardwareSupport : False
BTIKernelRetpolineEnabled : False
BTIKernelImportOptimizationEnabled : False
KVAShadowRequired : True
KVAShadowWindowsSupportPresent : True
KVAShadowWindowsSupportEnabled : True
KVAShadowPcidEnabled : True
SSBDWindowsSupportPresent : True
SSBDHardwareVulnerable : True
SSBDHardwarePresent : True
SSBDWindowsSupportEnabledSystemWide : False
L1TFHardwareVulnerable : True
L1TFWindowsSupportPresent : True
L1TFWindowsSupportEnabled : True
L1TFInvalidPteBit : 45
L1DFlushSupported : True
 
It's like you're just not even aware that Microsoft fired a significant amount of their QA staff a bunch of years ago.

I'm not contesting public beta branches, not even close.

What I'm pointing out, and effectively echo-chambering here (because I'm not the only one with this position) is that with Windows 10 and Windows Server 2016, Microsoft has been pushing out far more unstable and buggy code than in previous major versions. And by very wide margins.

In the lifespan of Windows 10, we've seen major public releases brick computers and BIOS' (creators update), delete user files (October 1809 release), and plenty of other substantial issues that never should have made it to the main release branch. And yet it did, and still does.

Windows 10 being a rolling release makes sense, except for the level of QA that Microsoft has been putting into it. Which is substantially lower than Windows 8, 7 and many other previous major releases.

If you think it's okay, that's on you. The rest of the industry, isn't okay with it. And I recommend you go actually look this up to see the impact this has had. It's not okay, and yet Microsoft thinks it's okay.

They do, they have software test engineers, a position that pays quite well (6 figures). However they also release test versions of software to the public so you can do your own testing, prior to release. This is useful to help find bugs because, I hate to break it to you, but no matter how much testing you do internally there's just way too many configurations in the world to test everything. It is also useful to organizations so they can test what is coming down the pipe and be ready for it.

But no, surely only MS is the only organization that releases test builds for people to try. I mean it isn't like FreeBSD has multiple releases... oh wait, it does. There's a Production branch, which is what is used for mainstream productions systems, a Stable branch that is in development but has been fairly tested, despite still being in development and a Current branch which is the bleeding edge development and has the least testing. Ok well that's surely an anomaly, nobody who does commercial software would do that. It isn't like Juniper Networks has multiple releases of Junos... oh wait, they do too! For any given platform there's a recommended Junos release which is the one that is most tested, stable, and supported for that platform and will continue to have engineering support for a long time. However you can get other newer (and older) releases too, each quarter there's a new Junos release and you can run them, but they aren't as tested, and there could be some issues. Finally you can opt in to getting development releases if you want to test bleeding edge stuff, though you have to contact them and convince them they should give you access.

Come on, give it a rest. It is not only common, but a good idea to have test code available to the public to test, if they want. Any sort of FOSS is going to do that, and many commercial organizations do the same. It doesn't mean they do no testing, if that were the case the release branch would be the same as the dev branch. It just means you can test it as well, if you wish.
 
So you propose they what? Just release the code with no testing?

Come on man, that is some silly MS-hate. The proper way to do things is to develop them, then put them through extensive testing. That's what they are doing. It is new, so it is in alpha testing. As it gets more tested it'll be moved downstream to eventual mainline release.

That would be a first in many, many years, if MS actually did what you say. Testing... That's called "the release ring" these days, is it not?
 
I don't get why people get upset over testing this on public because ever since Windows 95 you have been beta testing every release of Windows.
 
Microsoft has released some registry tweaks to manually enable these new optimizations.

On Client SKUs:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 0x400
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverrideMask /t REG_DWORD /d 0x400
Reboot

On Server SKUs:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 0x400
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverrideMask /t REG_DWORD /d 0x401
Reboot

I have enabled them on two of my 1809-based Windows 10 systems, none of them seem to have any issues with this tweak enabled. It appears that on newer systems with processors Skylake (and newer) such as my 8700K, Retpoline will not be enabled and only Import Optimization will be enabled.

So far I've seen certain programs already launch visibly faster than they did before I applied this tweak to my systems so that's good.
 
Microsoft has released some registry tweaks to manually enable these new optimizations.

On Client SKUs:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 0x400
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverrideMask /t REG_DWORD /d 0x400
Reboot

On Server SKUs:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 0x400
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverrideMask /t REG_DWORD /d 0x401
Reboot

I have enabled them on two of my 1809-based Windows 10 systems, none of them seem to have any issues with this tweak enabled. It appears that on newer systems with processors Skylake (and newer) such as my 8700K, Retpoline will not be enabled and only Import Optimization will be enabled.

So far I've seen certain programs already launch visibly faster than they did before I applied this tweak to my systems so that's good.


More about those reg data and incompatible cpus at:
https://www.bleepingcomputer.com/ne...erformance-with-retpoline-spectre-mitigation/
 
Back
Top