Difference between revisions of "Speculative Execution Vulnerabilities of 2018"
JeremyRand (talk | contribs) (→Attack surface reduction: Add hardware cost for reference) |
JeremyRand (talk | contribs) (→Attack surface reduction: Add MLFY link) |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 63: | Line 63: | ||
== Attack surface reduction == | == Attack surface reduction == | ||
| − | Some known speculative execution vulnerabilities, e.g. [[#MDS|MDS]], rely on the CPU sharing some state between SMT threads running on the same core. In response, some operating systems (such as [[Kicksecure]]) have disabled SMT <ref>[http://www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/wiki/Release_Notes#Security_Enhancements_7 Whonix 15 Security Enhancements]</ref><ref>[https://www.kicksecure.com/wiki/Packages_for_Debian_Hosts Kicksecure Packages for Debian Hosts]</ref><ref>[https://github.com/Whonix/security-misc#boot-parameters security-misc Boot parameters]</ref> in order to preemptively mitigate future speculative execution vulnerabilities. Given that POWER9 L2 and L3 cache is per-slice, not per-core <ref>[[POWER9]]</ref>, users who are disabling SMT and desire maximum protection from future speculative execution vulnerabilities may wish to | + | Some known speculative execution vulnerabilities, e.g. [[#MDS|MDS]], rely on the CPU sharing some state between SMT threads running on the same core. In response, some operating systems (such as [[Kicksecure]]) have disabled SMT <ref>[http://www.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/wiki/Release_Notes#Security_Enhancements_7 Whonix 15 Security Enhancements]</ref><ref>[https://www.kicksecure.com/wiki/Packages_for_Debian_Hosts Kicksecure Packages for Debian Hosts]</ref><ref>[https://github.com/Whonix/security-misc#boot-parameters security-misc Boot parameters]</ref> in order to preemptively mitigate future speculative execution vulnerabilities. Given that POWER9 L2 and L3 cache is per-slice, not per-core <ref>[[POWER9]]</ref>, users who are disabling SMT and desire maximum protection from future speculative execution vulnerabilities may wish to use CPU's with [[POWER9#Pairing|unpaired cores]]. Conversely, while disabling SMT and using unpaired cores is probably the most secure configuration, it is likely that using paired cores with SMT enabled will provide better security than unpaired cores with SMT enabled, because doing so increases the amount of cache noise, making attacks more difficult. |
| + | |||
| + | As an alternative to disabling SMT, you can use [https://github.com/JeremyRand/MLFY MLFY]. Unlike disabling SMT, MLFY will disable hardware threads that share cache. On CPU's that have unpaired cores, MLFY should be equivalent to disabling SMT; on CPU's that have paired cores, MLFY will also disable one core from each pair, thus achieving security properties that resemble unpaired cores. This can also yield slightly higher performance than using CPU's with unpaired cores, since CPU's with unpaired cores max out at 8 cores, while using MLFY with a CPU that has paired cores will yield 9 or 11 effective cores (for the 18 and 22 core parts). | ||
| + | |||
| + | To summarize: | ||
{| class="wikitable" | {| class="wikitable" | ||
| Line 72: | Line 76: | ||
! Performance | ! Performance | ||
! Hardware cost | ! Hardware cost | ||
| + | |- | ||
| + | | MLFY | ||
| + | | Unpaired | ||
| + | | 1 thread per cache (most secure, no shared state) | ||
| + | | 4 to 8 threads per CPU | ||
| + | | Cheap | ||
| + | |- | ||
| + | | MLFY | ||
| + | | Paired | ||
| + | | 1 thread per cache (most secure, no shared state) | ||
| + | | 9 to 11 threads per CPU | ||
| + | | Expensive | ||
|- | |- | ||
| Disabled | | Disabled | ||
| Line 81: | Line 97: | ||
| Disabled | | Disabled | ||
| Paired | | Paired | ||
| − | | 2 threads per cache (least secure, SNR 1:0) | + | | 2 threads per cache (least secure, SNR 1:0, same as most x86 systems with SMT enabled) |
| − | | 18 to 22 threads per CPU | + | | 18 to 22 threads per CPU (or 8 threads per CPU with configuration not sold by RCS) |
| Expensive | | Expensive | ||
|- | |- | ||
| Line 94: | Line 110: | ||
| Paired | | Paired | ||
| 8 threads per cache (very secure, SNR 1:6) | | 8 threads per cache (very secure, SNR 1:6) | ||
| − | | 72 to 88 threads per CPU | + | | 72 to 88 threads per CPU (or 32 threads per CPU with configuration not sold by RCS) |
| Expensive | | Expensive | ||
|} | |} | ||
Latest revision as of 04:07, 28 September 2022
In January of 2018, news of three speculative execution vulnerabilities was made public. Information about these vulnerabilities had been disclosed in private to certain companies and projects in June of 2016.
| CVE | Group | GPZ name[1] | Description |
|---|---|---|---|
| CVE-2017-5715 | Spectre | Variant 2 | indirect branch prediction with side-channel analysis[2] |
| CVE-2017-5753 | Spectre | Variant 1 | branch prediction with side-channel analysis[3] |
| CVE-2017-5754 | Meltdown | Variant 3 | indirect branch prediction with side-channel analysis of data cache[4] |
At this time we know that POWER9, POWER8, POWER8E, POWER7+, POWER6, and certain PowerPC architectures are affected by at least some of these vulnerabilities. [5][6][7][8]
Contents
CVE-2017-5715 (Spectre)
According to the official CVE list, this may affect processors using "speculative execution and indirect branch prediction". Google's Project Zero calls this Variant 2: branch target injection.
POWER9
Hardware fixes are in place for POWER9 Nimbus DD2.2 / Cumulus DD1.1 and above [9]. With these hardware changes, Spectre variant 2 is believed to be mitigated on the production POWER9 devices. Note that firmware applies the protections by throwing chicken switches in the silicon; as a result, the protection level is configurable via firmware flags.
CVE-2017-5753 (Spectre)
According to the official CVE list, this may affect processors using "speculative execution and branch prediction". Google's Project Zero calls this Variant 1: bounds check bypass.
POWER9
Hardware fixes are in place for POWER9 Nimbus DD2.2 / Cumulus DD1.1 and above [9]. With these hardware changes, cross-process attacks via Spectre variant 1 are believed to be fully mitigated on the production POWER9 devices.
CVE-2017-5754 (Meltdown)
According to the official CVE list, this may affect processors using "speculative execution and indirect branch prediction", but specifically uses a data cache side channel. Google's Project Zero calls this Variant 3: rogue data cache load.
Common Mitigations
POWER7, POWER8, and POWER9 are patched from CVE-2017-5754 by purging the L1 cache when context switching to a less privileged process, as the vulnerability on these architectures affects L1 but not L2 cache.[10] Firmware updates are also required to enable workarounds at the hardware level.[11] [12].
POWER9
Hardware fixes are also in place for POWER9 Nimbus DD2.2 / Cumulus DD1.1 and above [9]. In conjunction with the above kernel patch, Meltdown is fully mitigated on the production POWER9 devices.
MDS
IBM is stating that POWER is not vulnerable to MDS vulnerabilites (Fallout, RIDL, ZombieLoad) [13].
Official statement from Raptor Computing Systems regarding Talos™ II
POWER9 will not ship with vulnerability to Meltdown or any loss in performance compared with the current prototype chips (DD2.1). Further, Spectre is fully mitigated with the exception of the same-process issue that is affecting the entire CPU industry. As far as we are aware there will be no further mitigation from any major CPU vendor now or in the future, as the remaining Spectre issue has been deemed an application level programming issue versus a CPU design issue. Patches for GCC to help fix the affected applications are already rolling out.
Attack surface reduction
Some known speculative execution vulnerabilities, e.g. MDS, rely on the CPU sharing some state between SMT threads running on the same core. In response, some operating systems (such as Kicksecure) have disabled SMT [14][15][16] in order to preemptively mitigate future speculative execution vulnerabilities. Given that POWER9 L2 and L3 cache is per-slice, not per-core [17], users who are disabling SMT and desire maximum protection from future speculative execution vulnerabilities may wish to use CPU's with unpaired cores. Conversely, while disabling SMT and using unpaired cores is probably the most secure configuration, it is likely that using paired cores with SMT enabled will provide better security than unpaired cores with SMT enabled, because doing so increases the amount of cache noise, making attacks more difficult.
As an alternative to disabling SMT, you can use MLFY. Unlike disabling SMT, MLFY will disable hardware threads that share cache. On CPU's that have unpaired cores, MLFY should be equivalent to disabling SMT; on CPU's that have paired cores, MLFY will also disable one core from each pair, thus achieving security properties that resemble unpaired cores. This can also yield slightly higher performance than using CPU's with unpaired cores, since CPU's with unpaired cores max out at 8 cores, while using MLFY with a CPU that has paired cores will yield 9 or 11 effective cores (for the 18 and 22 core parts).
To summarize:
| SMT | Cores | Security | Performance | Hardware cost |
|---|---|---|---|---|
| MLFY | Unpaired | 1 thread per cache (most secure, no shared state) | 4 to 8 threads per CPU | Cheap |
| MLFY | Paired | 1 thread per cache (most secure, no shared state) | 9 to 11 threads per CPU | Expensive |
| Disabled | Unpaired | 1 thread per cache (most secure, no shared state) | 4 to 8 threads per CPU | Cheap |
| Disabled | Paired | 2 threads per cache (least secure, SNR 1:0, same as most x86 systems with SMT enabled) | 18 to 22 threads per CPU (or 8 threads per CPU with configuration not sold by RCS) | Expensive |
| Enabled | Unpaired | 4 threads per cache (relatively secure, SNR 1:2) | 16 to 32 threads per CPU | Cheap |
| Enabled | Paired | 8 threads per cache (very secure, SNR 1:6) | 72 to 88 threads per CPU (or 32 threads per CPU with configuration not sold by RCS) | Expensive |
To date, researchers have not successfully demonstrated attacks against 4 or 8 threads per cache. Whether this is because such attacks are too difficult to achieve or simply because they are inapplicable to x86 CPU's (where most of the research funding lives) remains to be seen.
See also
External Links
References
- ↑ Reading privileged memory with a side-channel. Google Project Zero blog
- ↑ CVE-2017-5715. Mitre CVE List. "Systems with microprocessors utilizing speculative execution and indirect branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis."
- ↑ CVE-2017-5753. Mitre CVE List. "Systems with microprocessors utilizing speculative execution and branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis."
- ↑ CVE-2017-5754. Mitre CVE List. "Systems with microprocessors utilizing speculative execution and indirect branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis of the data cache."
- ↑ IBM PSIRT Blog post, Potential Impact on Processors in the POWER family
- ↑ TenFourFox Development blog post, Actual field testing of Spectre on various Power Macs
- ↑ Raptor Engineering GNU Social notices about POWER8 and POWER9 vulnerability
- ↑ Red Hat security page for Kernel Side-Channel Attacks
- ↑ 9.0 9.1 9.2 Hostboot commit message listing security changes for NDD2.2 / CDD1.1
- ↑ Larabel, Michael. PowerPC Memory Protection Keys In For Linux 4.16, Power Has Meltdown Mitigation In 4.15. 2018-01-22
- ↑ IBM Power8 Systems Server Firmware
- ↑ IBM POWER9 Systems Server Firmware
- ↑ IBM Addresses Reported Intel Security Vulnerabilities
- ↑ Whonix 15 Security Enhancements
- ↑ Kicksecure Packages for Debian Hosts
- ↑ security-misc Boot parameters
- ↑ POWER9
