Create a gist now

Instantly share code, notes, and snippets.

@woachk /Spectre.md
Last active Mar 17, 2018

What would you like to do?

Spectre still unfixed, unlike what Intel says

Written by https://twitter.com/never_released , reviewed and corrected by Alex Ionescu

On January 4th, 3 separate vulnerabilities were released, the two first ones being named Spectre (Variant 1 and 2) and the third one being Meltdown (Variant 3).

Intel CPUs are affected by all vulnerabilities, as are Apple A-series CPUs used on iOS devices, nVidia Tegra X2, the ARM Cortex-A75 and the Qualcomm Snapdragon 845 CPUs. CPUs with speculative execution from other manufacturers (other ARM "big" cores, AMD CPUs, PowerPC, ...) are affected by Spectre but not Meltdown.

In-order CPUs (such as ARM Cortex-A7 or ARM Cortex-A53, as are Atoms before 2013) are not affected by Meltdown and Spectre.

Meltdown (Variant 3) : CVE-2017-5754

Meltdown has been fixed on the Linux kernel through a patchset named KPTI, which affects performance differently depending on the workload. The effects are negligible for typical desktop usage, but some server workloads are heavily impacted.

Windows was patched in November for Insider (beta) builds, and January 2018 for everyone else. The hit when having a CPU without the INVPCID feature (pre-Haswell CPUs) is bigger than more modern CPUs for Meltdown, the TLB has to be flushed on each interrupt or context switch on older CPUs.

PCID as implemented in Ivy Bridge and earlier isn't enough to use the faster path instead of a TLB flush, INVPCID as present on Haswell and later is required for Windows. On Linux, a faster path is used even when INVPCID isn't available.

KPTI is only available for 64-bit operating systems. Some 32-bit operating systems such as Mac OS X are immune because they use separate memory maps for kernel and userspace, at does Linux with a 4GB/4GB memory split.

Spectre (Variant 2) : CVE-2017-5715

Windows:

It's fixed on Windows on Intel and AMD systems with a microcode update delivered by the OEM, using IBPB and IBRS when available. If no microcode update is done, LFENCE is implemented on Windows as a mitigation for the kernel.

Linux:

Spectre (Variant 2) is still unfixed on Linux at this time.

It'll be fixed with a mitigation called retpoline (with 5-10% performance impact in server use, should be negligible for customers) on Intel CPUs, which requires recompiling applications for full protection.

On Skylake and later, retpoline is only "98%" effective, aka probably workaroundable in the future.

IBRS, a patchset with a performance impact which also requires newer microcode to work exists for security-concerned users who want to protect applications one from the other without individual per-app fixes (IBRS=2 setting). IBRS is currently available through microcode updates for Haswell and later.

On AMD CPUs, retpoline isn't needed and usage of the LFENCE instruction is enough to protect against Variant 2 of Spectre for the kernel. IBPB is available as a part of a microcode update to protect applications without recompiling (microcode update not currently fully rolled out, and kernel code not included in the official Linux tree yet).

Spectre (Variant 1) : CVE-2017-5753

Spectre (Variant 1) is a bounds-checking exploit during branching. This issue is fixed with a kernel patch which isn't mainlined yet in the Linux kernel according to Red Hat. The flaw shouldn't exist on Windows, but can exist on third-party drivers used on the operating system. It'll have to be fixed for JITs such as web browsers too, it allows reading all the data of the current process otherwise.

tl;dr

Meltdown is currently patched for Linux & Windows. Spectre (Variant 2) is underway for Linux and not done yet for mainline.

Spectre (Variant 1) isn't currently patched on Linux, and the Windows kernel is immune unless one of the installed drivers is vulnerable. Applications interpreting/JITting untrusted code such as web browsers need updates regardless of OS updates for Spectre (Variant 1).

Windows:

On Windows, Spectre (Variant 2) is patched for user-mode applications if Intel or AMD microcode updates are applied via a BIOS/UEFI update, ask your OEM/PC manufacturer for an firmware update that adds December/January 2018 microcode. Otherwise, application-specific updates are required, and only the kernel is protected (an app can snoop on another application, or even a browser tab on your passwords and such in theory).

Warning: For Windows systems, microcode updates have to be shipped via the BIOS/UEFI to protect against Spectre (Variant 2) across applications.

Warning 2: 32-bit Windows does not have Meltdown patches. Beware.

Warning 3: Windows XP/Vista and Windows Server 2003/2008 will never get Meltdown updates. Windows 8.0 is out of support, it'll not get Meltdown updates too.

Linux:

This section doesn't apply yet, Linux isn't patched against Spectre. Vendor-specific kernels that have patches against those aren't properly validated and can result in data corruption. Some of them might not even boot on some machines. They're also not optimized and can cause large performance regressions.

The kernel is protected against Spectre (Variant 2) but application-specific patches are required except when IBPB=2 + STIBP, IBRS=1 + IBPB=1, or IBRS=2 are used.

Application-specific updates will be required to mitigate against Spectre (Variant 2) when IBRS=1 without IBPB, LFENCE, or retpoline mitigations are used kernel-side. Retpoline isn't fully effective for Skylake and later microarchitectures.


Notes:

  • On Windows Server, KvaShadow (KPTI) and IBRS are disabled by default because of the performance impact, and have to be explicitly enabled by the administrator if he's concerned enough about security.

  • On Windows (client), the update is only downloaded if the antivirus vendor did set a registry key, for compatibility reasons.

  • macOS warning: The security flaw is not fixed in macOS 10.12 or 10.11, but only in High Sierra, Apple modified their support website to reflect this ( https://twitter.com/mikeymikey/status/949345240099377152 )

  • "The microcode is delivered through a firmware update. Consult with the device manufacturer about the firmware version that has the appropriate update for your CPU." infers that the microcode necessary for mitigating Spectre (Variant 2) cannot be applied by Windows, but requires OEM action.

  • On pre-Ryzen AMD CPUs, IBRS=2 and IBPB=1 is enabled by default on Red Hat to provide protection. On Ryzen, IBPB=2 is enabled instead.

  • ibpb=2 doesn’t protect the kernel against attacks based on simultaneous multi-threading (SMT, also known as hyperthreading); therefore, ibpb=2 provides less complete protection unless SMT is also disabled or STIBP is used. IBPB addresses Spectre (Scenario 2).

  • About the microcode update for Zen 1 CPUs being described as "disabling branch prediction", this is a mistake in the description of the update.

  • When Intel® OS Guard, also known as Supervisor-Mode Execution Prevention (SMEP), is enabled, the operating system will not be allowed to directly execute application code, even speculatively.

@hwti

This comment has been minimized.

Show comment Hide comment
@hwti

hwti Jan 6, 2018

For Windows, there is something I don't understand : if retpoline was implemented dynamically, there would no reason to enable it on AMD.
So it means there is only one code path, so it is also used on Intel even if the microcode update is done (so performance impacts are added). Then perhaps the sentence should be "Windows always uses retpoline, so even if no microcode update is done, there is still a mitigation".

So it would be :

  • Intel : IBRS (if new microcode) + retpoline (even if unneed with IBRS)
  • AMD : lfence + retpoline (unneeded)

That is : retpoline slows down everyone, to protect older or non microcode-updated Intel CPUs.

hwti commented Jan 6, 2018

For Windows, there is something I don't understand : if retpoline was implemented dynamically, there would no reason to enable it on AMD.
So it means there is only one code path, so it is also used on Intel even if the microcode update is done (so performance impacts are added). Then perhaps the sentence should be "Windows always uses retpoline, so even if no microcode update is done, there is still a mitigation".

So it would be :

  • Intel : IBRS (if new microcode) + retpoline (even if unneed with IBRS)
  • AMD : lfence + retpoline (unneeded)

That is : retpoline slows down everyone, to protect older or non microcode-updated Intel CPUs.

@Symbian9

This comment has been minimized.

Show comment Hide comment
@Symbian9

Symbian9 Jan 6, 2018

@woachk, please, check related issue in Pale Moon

Are there good PoC's for test Spectre attack in web-browser?

Symbian9 commented Jan 6, 2018

@woachk, please, check related issue in Pale Moon

Are there good PoC's for test Spectre attack in web-browser?

@woachk

This comment has been minimized.

Show comment Hide comment
@woachk

woachk Jan 6, 2018

@hwti retpoline impact is low in kernel code (1-1.5%), but is higher in user-space code when all the user apps will be recompiled.

Owner

woachk commented Jan 6, 2018

@hwti retpoline impact is low in kernel code (1-1.5%), but is higher in user-space code when all the user apps will be recompiled.

@CHoldredge

This comment has been minimized.

Show comment Hide comment
@CHoldredge

CHoldredge Jan 6, 2018

Do I misunderstand the scope of Spectre version 2? (probably, TBH)

Parches using Reptoline and IBRS calls to defend jump operations are being applied to OS kernels, which will prevent their memory from being investigated by malicious user processes. Can't the same attack be performed against security-critical applications, if an attacker can find an appropriate 'gadget' in their code? Won't all applications that contain confidential data need to be patched to use retpoline or IBRS on potentially-critical jump operations?

If that is the case, saying "it's fixed on Windows" seems dangerously misleading. People like me who are more security implementer than security researcher could assume they're completely protected from that version because they've applied an OS patch, when in fact there's much more to be done.

If that's right (and again, I'm probably wrong) it seems it might be better to say "It's fixed in the Windows OS on Intel systems with... Similar changes will have to be implemented for Windows applications"

CHoldredge commented Jan 6, 2018

Do I misunderstand the scope of Spectre version 2? (probably, TBH)

Parches using Reptoline and IBRS calls to defend jump operations are being applied to OS kernels, which will prevent their memory from being investigated by malicious user processes. Can't the same attack be performed against security-critical applications, if an attacker can find an appropriate 'gadget' in their code? Won't all applications that contain confidential data need to be patched to use retpoline or IBRS on potentially-critical jump operations?

If that is the case, saying "it's fixed on Windows" seems dangerously misleading. People like me who are more security implementer than security researcher could assume they're completely protected from that version because they've applied an OS patch, when in fact there's much more to be done.

If that's right (and again, I'm probably wrong) it seems it might be better to say "It's fixed in the Windows OS on Intel systems with... Similar changes will have to be implemented for Windows applications"

@woachk

This comment has been minimized.

Show comment Hide comment
@woachk

woachk Jan 6, 2018

@CHoldredge That's right for retpoline... IBRS option 2 fix it without recompiling though.

When IBRS is set to 2, both userland and kernel runs with indirect branch restricted speculation. This protects userspace from hyperthreading/simultaneous multi-threading attacks as well, and is also the default on AMD processors (family 10h, 12h and 16h). This feature addresses CVE-2017-5715, variant #2.

Owner

woachk commented Jan 6, 2018

@CHoldredge That's right for retpoline... IBRS option 2 fix it without recompiling though.

When IBRS is set to 2, both userland and kernel runs with indirect branch restricted speculation. This protects userspace from hyperthreading/simultaneous multi-threading attacks as well, and is also the default on AMD processors (family 10h, 12h and 16h). This feature addresses CVE-2017-5715, variant #2.

@hwti

This comment has been minimized.

Show comment Hide comment
@hwti

hwti Jan 6, 2018

@woachk So IBRS/IBPB would be enabled for all code, I tought it would only be on the kernel.

Applications currently compiled with security flags (like stack protector) should enable retpoline. It makes sense for a browser which runs JavaScript for example.
But applications which don't process untrusted inputs, or protect any secret, like compilers for example, don't need this.
This is the same for IBRS/IBPB, so a per-application control would be helpful.

hwti commented Jan 6, 2018

@woachk So IBRS/IBPB would be enabled for all code, I tought it would only be on the kernel.

Applications currently compiled with security flags (like stack protector) should enable retpoline. It makes sense for a browser which runs JavaScript for example.
But applications which don't process untrusted inputs, or protect any secret, like compilers for example, don't need this.
This is the same for IBRS/IBPB, so a per-application control would be helpful.

@woachk

This comment has been minimized.

Show comment Hide comment
@woachk

woachk Jan 6, 2018

@hwti IBRS is only IBRS=1 by default on Intel CPUs, because it's too expensive there to do IBRS=2...
It's "cheap" enough on AMD CPUs to be useable there.

Owner

woachk commented Jan 6, 2018

@hwti IBRS is only IBRS=1 by default on Intel CPUs, because it's too expensive there to do IBRS=2...
It's "cheap" enough on AMD CPUs to be useable there.

@hwti

This comment has been minimized.

Show comment Hide comment
@hwti

hwti Jan 6, 2018

@woachk What do you mean by IBRS=1 ?

The performance impact will depend a lot on the CPU and the workload (at least for KPTI/KVaShadow, I don't know for IBRS/IBPB).
For example, I've seen reports of 30-50% slowdown for "du -s" with KPTI, which make me fear "git status" would be impacted too.
Then, for developpers using customized shell prompts to show repository status, the impact could be visible.

hwti commented Jan 6, 2018

@woachk What do you mean by IBRS=1 ?

The performance impact will depend a lot on the CPU and the workload (at least for KPTI/KVaShadow, I don't know for IBRS/IBPB).
For example, I've seen reports of 30-50% slowdown for "du -s" with KPTI, which make me fear "git status" would be impacted too.
Then, for developpers using customized shell prompts to show repository status, the impact could be visible.

@woachk

This comment has been minimized.

Show comment Hide comment
@woachk

woachk Jan 6, 2018

@hwti When ibrs_enabled is set to 1 the kernel runs with indirect branch restricted speculation, which protects the kernel space from attacks (even from hyperthreading/simultaneous multi-threading attacks). When IBRS is set to 2, both userland and kernel runs with indirect branch restricted speculation. This protects userspace from hyperthreading/simultaneous multi-threading attacks as well, and is also the default on AMD processors (family 10h, 12h and 16h).

It's the IBRS protection level number 1, you need number 2 for full protection... or IBPB.

Owner

woachk commented Jan 6, 2018

@hwti When ibrs_enabled is set to 1 the kernel runs with indirect branch restricted speculation, which protects the kernel space from attacks (even from hyperthreading/simultaneous multi-threading attacks). When IBRS is set to 2, both userland and kernel runs with indirect branch restricted speculation. This protects userspace from hyperthreading/simultaneous multi-threading attacks as well, and is also the default on AMD processors (family 10h, 12h and 16h).

It's the IBRS protection level number 1, you need number 2 for full protection... or IBPB.

@hwti

This comment has been minimized.

Show comment Hide comment
@hwti

hwti Jan 6, 2018

@woachk ibrs_enabled is a Linux setting.
For Windows, are IBRS/IBPB enabled only on kernel, or on applications too ?
Both the official PowerShell script and Alex Ionescu's tool only report boolean values.

hwti commented Jan 6, 2018

@woachk ibrs_enabled is a Linux setting.
For Windows, are IBRS/IBPB enabled only on kernel, or on applications too ?
Both the official PowerShell script and Alex Ionescu's tool only report boolean values.

@woachk

This comment has been minimized.

Show comment Hide comment
@woachk

woachk Jan 6, 2018

Applications are protected on Windows as long as you apply the microcode update. @hwti

Owner

woachk commented Jan 6, 2018

Applications are protected on Windows as long as you apply the microcode update. @hwti

@hwti

This comment has been minimized.

Show comment Hide comment
@hwti

hwti Jan 6, 2018

@woachk The userspace case of Spectre (Variant 1) can exist on Windows : a JavaScript code could use a similar approach to read browser memory (in the same process).

hwti commented Jan 6, 2018

@woachk The userspace case of Spectre (Variant 1) can exist on Windows : a JavaScript code could use a similar approach to read browser memory (in the same process).

@woachk

This comment has been minimized.

Show comment Hide comment
@woachk

woachk Jan 6, 2018

@hwti common sense tells you to leave untrusted code in a separate process as private data though. Fix done :)

Owner

woachk commented Jan 6, 2018

@hwti common sense tells you to leave untrusted code in a separate process as private data though. Fix done :)

@stefangeorgeclaudiu

This comment has been minimized.

Show comment Hide comment
@stefangeorgeclaudiu

stefangeorgeclaudiu Jan 7, 2018

It appears that nVidia GPUs and CPUs also affected by Spectre side-channel attacks: https://www.nvidia.com/en-us/product-security/

stefangeorgeclaudiu commented Jan 7, 2018

It appears that nVidia GPUs and CPUs also affected by Spectre side-channel attacks: https://www.nvidia.com/en-us/product-security/

@woachk

This comment has been minimized.

Show comment Hide comment
@woachk

woachk Jan 7, 2018

@stefangeorgeclaudiu nVidia GPU drivers were updated for Spectre Variant 1 fixes. Apart from Tegra X2, other nVidia CPUs are not affected by Meltdown. GPUs themselves aren't affected by those flaws.

Owner

woachk commented Jan 7, 2018

@stefangeorgeclaudiu nVidia GPU drivers were updated for Spectre Variant 1 fixes. Apart from Tegra X2, other nVidia CPUs are not affected by Meltdown. GPUs themselves aren't affected by those flaws.

@stefangeorgeclaudiu

This comment has been minimized.

Show comment Hide comment
@stefangeorgeclaudiu

stefangeorgeclaudiu Jan 7, 2018

@woachk I was thinking more in the lines of CUDA applications sharing the same GPU as I've read newer GPUs support concurrent kernel execution. It's reassuring to know there is no risk. Thanks

@woachk I was thinking more in the lines of CUDA applications sharing the same GPU as I've read newer GPUs support concurrent kernel execution. It's reassuring to know there is no risk. Thanks

@deadm0roz

This comment has been minimized.

Show comment Hide comment
@deadm0roz

deadm0roz Jan 8, 2018

The flaw shouldn't exist on Windows, but can exist on third-party drivers used on the operating system

Can you describe, what is the basis of this statement? There's no information about it in official Microsoft's advisory.

The flaw shouldn't exist on Windows, but can exist on third-party drivers used on the operating system

Can you describe, what is the basis of this statement? There's no information about it in official Microsoft's advisory.

@woachk

This comment has been minimized.

Show comment Hide comment
@woachk

woachk Jan 8, 2018

@deadm0roz nVidia GPU drivers on Windows for example had to have an update to protect against Spectre Variant 1, see nVidia's advisory.

Owner

woachk commented Jan 8, 2018

@deadm0roz nVidia GPU drivers on Windows for example had to have an update to protect against Spectre Variant 1, see nVidia's advisory.

@deadm0roz

This comment has been minimized.

Show comment Hide comment
@deadm0roz

deadm0roz Jan 8, 2018

@woachk I know, but how does it relate to kernel affection? Drivers may be patched to simply reduce attack surface, even if kernel is vulnerable, but you say that

Windows kernel is immune

@woachk I know, but how does it relate to kernel affection? Drivers may be patched to simply reduce attack surface, even if kernel is vulnerable, but you say that

Windows kernel is immune

@woachk

This comment has been minimized.

Show comment Hide comment
@deadm0roz

This comment has been minimized.

Show comment Hide comment
@deadm0roz

deadm0roz Jan 8, 2018

@woachk There're two references to kernel on that page:

In client scenarios, a malicious user mode application could be used to disclose the contents of kernel memory.

In server scenarios, a malicious user-mode application could be used to disclose the contents of kernel memory.

Nothing else about kernel or about unpatched drivers. Also in output of Microsoft's PS SpeculationControl module only Meltdown and Spectre v.2 mentioned, so KB4056892 probably doesn't fix Spectre v.1. And if kernel isn't vulnerable to Spectre v.1 initially, why all three vulnerabilities are mentioned in the advisory?

I really don't understand, how did you come to your conclusion. Maybe you saw other revision of that page?

deadm0roz commented Jan 8, 2018

@woachk There're two references to kernel on that page:

In client scenarios, a malicious user mode application could be used to disclose the contents of kernel memory.

In server scenarios, a malicious user-mode application could be used to disclose the contents of kernel memory.

Nothing else about kernel or about unpatched drivers. Also in output of Microsoft's PS SpeculationControl module only Meltdown and Spectre v.2 mentioned, so KB4056892 probably doesn't fix Spectre v.1. And if kernel isn't vulnerable to Spectre v.1 initially, why all three vulnerabilities are mentioned in the advisory?

I really don't understand, how did you come to your conclusion. Maybe you saw other revision of that page?

@woachk

This comment has been minimized.

Show comment Hide comment
@woachk

woachk Jan 9, 2018

@deadm0roz Fixes against Spectre v1 are included.

Owner

woachk commented Jan 9, 2018

@deadm0roz Fixes against Spectre v1 are included.

@marcan

This comment has been minimized.

Show comment Hide comment
@marcan

marcan Jan 22, 2018

There is no way "Variant 1" is "fixed" in Windows. Variant 1 is a pervasive problem that could potentially affect any code sequence where sensitive data is guarded by a conditional branch which contains a microarchitectural side-effect. There is no unconditional "fix". You can fix specific easily exploitable issues (like JIT bounds checks and userspace memory accesses in the kernel), you can harden code, but there is no way to claim "yeah it's fixed, everywhere" unless you do a formal analysis of your entire codebase. It doesn't just affect JITs (those are just easy to exploit); it affects the kernel, it affects local services. Under certain conditions it could even be remotely exploitable, though that is a bit of a stretch. Anyone claiming otherwise is spewing bullshit. The only fix for Variant 1 is to start teaching CS students what a speculation fence instruction is and to insert into all potentially vulnerable code, manually.

Variant 3 is an Intel fuckup. Variant 2 is an Intel and AMD fuckup. Variant 1 is a a fuckup of the entire field of computer science as applied in all modern CPUs with speculative execution. The latter isn't going away any time soon.

marcan commented Jan 22, 2018

There is no way "Variant 1" is "fixed" in Windows. Variant 1 is a pervasive problem that could potentially affect any code sequence where sensitive data is guarded by a conditional branch which contains a microarchitectural side-effect. There is no unconditional "fix". You can fix specific easily exploitable issues (like JIT bounds checks and userspace memory accesses in the kernel), you can harden code, but there is no way to claim "yeah it's fixed, everywhere" unless you do a formal analysis of your entire codebase. It doesn't just affect JITs (those are just easy to exploit); it affects the kernel, it affects local services. Under certain conditions it could even be remotely exploitable, though that is a bit of a stretch. Anyone claiming otherwise is spewing bullshit. The only fix for Variant 1 is to start teaching CS students what a speculation fence instruction is and to insert into all potentially vulnerable code, manually.

Variant 3 is an Intel fuckup. Variant 2 is an Intel and AMD fuckup. Variant 1 is a a fuckup of the entire field of computer science as applied in all modern CPUs with speculative execution. The latter isn't going away any time soon.

@phuclv90

This comment has been minimized.

Show comment Hide comment
@phuclv90

phuclv90 Feb 1, 2018

Some 32-bit operating systems such as Mac OS X are immune because they use separate memory maps for kernel and userspace, at does Linux with a 4GB/4GB memory split.

Note that by default Linux uses a 3GB/1GB split, although it's configurable to 2/2, 1/3 or 4/4

phuclv90 commented Feb 1, 2018

Some 32-bit operating systems such as Mac OS X are immune because they use separate memory maps for kernel and userspace, at does Linux with a 4GB/4GB memory split.

Note that by default Linux uses a 3GB/1GB split, although it's configurable to 2/2, 1/3 or 4/4

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment