Old document, do not use anymore.

Spectre.md

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:

It's 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.

Windows:

Warning: _For Windows systems, microcode updates have to be shipped via the BIOS/UEFI to protect against Spectre (Variant 2) across applications. They are manually downloadable via Windows Update too. _

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:

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 )

• 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. The update adds support for IBPB.

• 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.

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.

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.

@woachk, please, check related issue in Pale Moon

• MoonchildProductions/Pale-Moon#1568

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

@woachk, please, check related issue in Pale Moon

• MoonchildProductions/Pale-Moon#1568

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

@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.

@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.

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"

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 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.

@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.

@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 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 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 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.

@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 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 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 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.

@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 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.

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

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

@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 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 common sense tells you to leave untrusted code in a separate process as private data though. Fix done :)

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

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

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

@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 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.

@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

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.

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

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

@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

@deadm0roz https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV180002
The kernel is safe.

@deadm0roz https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV180002
The kernel is safe.

@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 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 Fixes against Spectre v1 are included.

@deadm0roz Fixes against Spectre v1 are included.

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.

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.

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

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