Retpoline Patch to Reduce Spectre v2 Slowdowns on Windows 10

News
By
published

(Image credit: Production Perig/Shutterstock)

After the Spectre mitigations caused relative slowdowns on some CPU microarchitectures and on certain workloads, Microsoft Windows engineers have announced that they will be implementing Google’s Retpoline mitigation for Spectre variant 2 (CVE- 2017-5715). 

Spectre V2 Patches

Google was already testing Retpoline on its own servers for months before the Spectre bug was made public because the company’s Project Zero team was among the researchers that found out that Spectre existed. However, Google made Retpoline public only a day after the Spectre bug leaked. By then, Microsoft and Intel, which also learned about the Spectre bug months earlier, had already developed their own patch that mitigated against Spectre V2. However, you had to receive the microcode update from your motherboard or laptop OEM.

Another problem is Microsoft’s patch has a significantly larger impact on performance compared to Google’s Retpoline. As such, the Windows developers have begun working on an implementation of the Retpoline mitigation for Windows 10.

The patch will not arrive to Windows 10 users until the next major Windows 10 update in the first half of 2019. Furthermore, Microsoft will not backport the Retpoline patch to previous versions of Windows, including older builds of Windows 10.

What Does the Retpoline Patch Do?

Spectre v2 is a “branch target injection” vulnerability which leverages the speculative execution behavior of the CPU to cause some code to leak information that can then be used in an attack against a host machine.

According to Google, Retpoline “sequences” are a software construct that allows indirect branches to be isolated from speculative execution. This solution could be applied to protect sensitive binaries of an operating system or a hypervisor implementation from branch target injections against their indirect branches.

The name of Retpoline is a combination of the words “return” and “trampoline.” Why trampoline, you ask? That’s because when using return operations, any associated speculative execution will 'bounce' endlessly.

In previous posts, Google said that the performance impact of Retpoline is negligible. Windows kernel developer Mehmet Iyigun also said on Twitter that the new patch will reduce the performance impact of Spectre v2 mitigations to “noise-level" for most scenarios.

In case it wasn’t already clear, the Retpoline patch doesn’t affect any of the other speculative execution vulnerabilities that have been disclosed this year.

Lucian Armasu
Lucian Armasu
Lucian Armasu is a Contributing Writer for Tom's Hardware US. He covers software news and the issues surrounding privacy and security.
9 Comments Comment from the forums
  • hannibal
    How does this relate to this?
    https://www.tomshardware.com/news/spectre-meltdown-flaws-solution-mit,37950.html
    Reply
  • alextheblue
    21415591 said:
    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.
    Reply
  • 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.
    Reply
  • alextheblue
    21419880 said:
    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.
    Reply
  • audiospecaccts
    21420220 said:
    21419880 said:
    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.
    Reply
  • 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!
    Reply
  • 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)
    Reply
  • audiospecaccts
    21421644 said:
    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.


    Reply
  • alextheblue
    21423116 said:
    21421644 said:
    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!
    Reply