Retpoline Patch to Reduce Spectre v2 Slowdowns on Windows 10

[Lucian Armasu]

Windows kernel developer admitted on Twitter that Google's "Retpoline" patch, which lowers the performance impact of Spectre v2 mitigations to "noise levels," will come to Windows 10 in an update in the first half of 2019.

Retpoline Patch to Reduce Spectre v2 Slowdowns on Windows 10 : Read more

 

[hannibal]

How does this relate to this?
https://www.tomshardware.com/news/spectre-meltdown-flaws-solution-mit,37950.html

 

[alextheblue]

Windows kernel developer admitted on Twitter that Google's "Retpoline" patch, which lowers the performance impact of Spectre v2 mitigations to "noise levels," will come to Windows 10 in an update in the first half of 2019.

Retpoline Patch to Reduce Spectre v2 Slowdowns on Windows 10 : Read more

First, they didn't just apply Google's "Retpoline patch". MS had to implement Retpoline in the Windows kernel. That's why it's not enabled in current releases and won't be until the next big update (they continued to improve and update it after the fork, so what is present in October is not good enough to switch on). Second, they didn't ONLY implement Retpoline. There's additional tweaks present, for example what they are calling "import optimization" which cuts down on the overhead of indirect calls in kernel mode.

But you probably knew that and just didn't bother.

 

[audiospecaccts]

Interesting that microsoft has not looked at the toolchain in their c++ compiler. Others have discovered this flaw in the gcc earlier this year. On debain based linux distributions, the official status is:
"
Current Status

Kernel updates have been shipped for Debian stable/stretch and later.

The gcc compiler toolchain was updated in Debian buster/unstable (gcc 7.3), stretch (gcc 6) through DSA-4121 and jessie (gcc 4.9) through DSA-4117. No archive rebuild is planned at this point so user-space fixes (particularly for Spectre v1) vary according to the affected binary package, as the fix is basically per-program. The compiler updates were still required to provide fixes for the Linux kernel."

For more info, read the full report on the official Debain wiki site:
https://wiki.debian.org/DebianSecurity/SpectreMeltdown#A64-bit_PC_.28amd64.29

Spectre Variant 2 can be exploited both locally (within the same OS) and through the virtualization guest boundary. Fixes require CPU microcode/firmware to activate. Subscribers are advised to contact their hardware OEM to receive the appropriate microcode/firmware for their processor. In particular, qemu and other hypervisors need to pass through certain CPU features to allow guest operating systems to correctly configuration mitigation mechanisms.

 

[alextheblue]

Interesting that microsoft has not looked at the toolchain in their c++ compiler. Others have discovered this flaw in the gcc earlier this year. On debain based linux distributions, the official status is:

In your own source, they're primarily discussing v1. They specifically state that v2 requires CPU microcode to fix. That's the existing fix that slows systems down. What the TH article is discussing is a different way to mitigate v2 without the performance hit, especially when combined with other tweaks MS is applying like import optimization.

What remains to be seen is if newer versions of these exploits are effectively halted, or if we'll once again require firmware/hardware/hybrid mitigations.

 

[audiospecaccts]

Interesting that microsoft has not looked at the toolchain in their c++ compiler. Others have discovered this flaw in the gcc earlier this year. On debain based linux distributions, the official status is:

In your own source, they're primarily discussing v1. They specifically state that v2 requires CPU microcode to fix. That's the existing fix that slows systems down. What the TH article is discussing is a different way to mitigate v2 without the performance hit, especially when combined with other tweaks MS is applying like import optimization.

What remains to be seen is if newer versions of these exploits are effectively halted, or if we'll once again require firmware/hardware/hybrid mitigations.

Its a microcode fix but I don't know how effective its going to be considering there could be a flaw in the XML language itself causing this. I own several web servers and I log every url requests off the sites remotely, and I found XML script requests from unknown behind an anonymous vpn that end up them getting root file system access. It wouldn't take much for them installing a bot to break in and seed victims and delete itself after a predetermined time. So I got rid of xml on those servers and they just get a 400 error now on their XML scripts they send.


This is another parallel to the guys who copy the SSL server keys on sites to hijack the IP and host a darkweb server on it.
The same effect happens to machines if the encryption keys in the hardware are copied.

 

[rantoc]

If they only made the predictive execution follow the security procedures to begin with rather than do it the lazy way and we wouldn't be having this crap to begin with!

 

[audiospecaccts]

I think they should just stick to making (or at least make available) processors with the basics like MMU (memory management unit), CPU (central processing unit) , FPU (floating point unit), and BIU (buss interface unit) only inside. A processor with all kinds of features needs R&D time of at least three years and none of the bebug/test stages should be implemented in the field (unlike other consumer products)

 

[audiospecaccts]

If they only made the predictive execution follow the security procedures to begin with rather than do it the lazy way and we wouldn't be having this crap to begin with!

Predictive execution should not be allowed ever. Because you can not bring order to chaos no matter how hard you try.

Linus Torvalds was right. Those processor guys are idiots. What are they doing? Are they getting pointers from other idiots from Microsoft? Seems like the same bad methodology.

 

[alextheblue]

If they only made the predictive execution follow the security procedures to begin with rather than do it the lazy way and we wouldn't be having this crap to begin with!

Predictive execution should not be allowed ever. Because you can not bring order to chaos no matter how hard you try.

Linus Torvalds was right. Those processor guys are idiots. What are they doing? Are they getting pointers from other idiots from Microsoft? Seems like the same bad methodology.

Linus couldn't design a competitive processor if he spent his entire life doing nothing else. Listening to his rants about things well out of his purview is a good source of entertainment, not education. There's a REASON all modern processor architectures use speculative execution. Oh but here come armchair engineers to the rescue! LOL!