Difference between revisions of "Speculative Execution Vulnerabilities of 2018"

From RCS Wiki
Jump to navigation Jump to search
m (add section "See also" and link to Configuring Spectre Protection Level)
 
(9 intermediate revisions by the same user not shown)
Line 52: Line 52:
  
 
Hardware fixes are also in place for [[POWER9]] Nimbus DD2.2 / Cumulus DD1.1 and above <ref name="hostboot-commit-fcf7d0e3">[https://git.raptorcs.com/git/talos-hostboot/commit/?id=fcf7d0e3f5fe8013b8f88a70a4f69cb5c0efc38b Hostboot commit message listing security changes for NDD2.2 / CDD1.1]</ref>.  In conjunction with the above kernel patch, Meltdown is fully mitigated on the production POWER9 devices.
 
Hardware fixes are also in place for [[POWER9]] Nimbus DD2.2 / Cumulus DD1.1 and above <ref name="hostboot-commit-fcf7d0e3">[https://git.raptorcs.com/git/talos-hostboot/commit/?id=fcf7d0e3f5fe8013b8f88a70a4f69cb5c0efc38b Hostboot commit message listing security changes for NDD2.2 / CDD1.1]</ref>.  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 [https://en.wikipedia.org/wiki/Microarchitectural_Data_Sampling MDS vulnerabilites] (Fallout, RIDL, ZombieLoad) <ref>[https://www.ibm.com/blogs/psirt/ibm-addresses-reported-intel-security-vulnerabilities/ IBM Addresses Reported Intel Security Vulnerabilities]</ref>.
  
 
== Official statement from Raptor Computing Systems regarding Talos™ II ==
 
== 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.
 
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|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"
 +
|+ SMT and Core Pairing Impact on Security
 +
! 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 ==
 
== See also ==

Latest revision as of 03: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]

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 and Core Pairing Impact on Security
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

  1. ↑ Reading privileged memory with a side-channel. Google Project Zero blog
  2. ↑ 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."
  3. ↑ 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."
  4. ↑ 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."
  5. ↑ IBM PSIRT Blog post, Potential Impact on Processors in the POWER family
  6. ↑ TenFourFox Development blog post, Actual field testing of Spectre on various Power Macs
  7. ↑ Raptor Engineering GNU Social notices about POWER8 and POWER9 vulnerability
  8. ↑ Red Hat security page for Kernel Side-Channel Attacks
  9. ↑ 9.0 9.1 9.2 Hostboot commit message listing security changes for NDD2.2 / CDD1.1
  10. ↑ Larabel, Michael. PowerPC Memory Protection Keys In For Linux 4.16, Power Has Meltdown Mitigation In 4.15. 2018-01-22
  11. ↑ IBM Power8 Systems Server Firmware
  12. ↑ IBM POWER9 Systems Server Firmware
  13. ↑ IBM Addresses Reported Intel Security Vulnerabilities
  14. ↑ Whonix 15 Security Enhancements
  15. ↑ Kicksecure Packages for Debian Hosts
  16. ↑ security-misc Boot parameters
  17. ↑ POWER9
Retrieved from "https://wiki.raptorcs.com/w/index.php?title=Speculative_Execution_Vulnerabilities_of_2018&oldid=3952"