Security vulnerability: RETBLEED transient execution information leak side-channel attack (CVE-2022-29900, CVE-2022-29901, CVE-2022-23825, CVE-2022-28693)
This document (000020693) is provided subject to the disclaimer at the end of this document.
Environment
For a comprehensive list of affected products please review the SUSE CVE announcements:
- https://www.suse.com/security/cve/CVE-2022-29900
- https://www.suse.com/security/cve/CVE-2022-29901
- https://www.suse.com/security/cve/CVE-2022-28693
- https://www.suse.com/security/cve/CVE-2022-23825
Situation
In certain scenarios the return instructions turn to use the indirect branch predictor, which can be influenced by Branch Target Injection attacks aka Spectre-BTI.
This allows local attackers to execute code to leak sensitive data out of the kernel, same as other Spectre like vulnerabilities.
Affected CPUs:
- Intel Skylake and newer Intel x86 CPU generations
- AMD Bulldozer (family 0x15) up to Zen 3
- Arm CPUs that are also vulnerable to Spectre variant 2
Resolution
- IBPB (Indirect Branch Prediction Barrier) can be used to flush the indirect branch predictor. This has performance impact, but is the safest option.
- On Intel Skylake the IBRS feature is used (Indirect Branch Restricted Speculation), which clears the branch history buffer from lower privileged entries.
Options:
- retbleed=off
SP4 and newer, but with the October 2022 kernel update releases this is available for all SUSE Linux
Enterprise 12 and 15 service packs.
- retbleed=auto
- retbleed=auto,nosmt
- retbleed=unret
If this option is selected on a non-supported CPU, it will be reported in the sysfs variable.
- retbleed=unret,nosmt
On Zen 1 systems hyperthreading is additionally disabled.
- retbleed=ibpb
This has the highest performance impact, but is also safest.
- spectre_v2=ibrs
Note that this is in the spectre_v2 space, as this spectrev2 mitigation is used also for RETBLEED.
Status:
The status can be found in /sys/devices/system/cpu/vulnerabilities/retbleed:
"Not affected"
The CPU is not affected by RETBLEED.
"Vulnerable"
The CPU is vulnerable to RETBLEED, no mitigations are enabled.
"Vulnerable: untrained return thunk on non-Zen uarch"
The CPU is vulnerable to RETBLEED, the mitigation "unret" was selected but it
is not supported on the CPU.
"Mitigation: untrained return thunk; SMT disabled"
AMD mitigation "untrained return thunk" enabled and hyperthreading disabled.
"Mitigation: untrained return thunk; SMT enabled with STIBP protection"
AMD mitigation "untrained return thunk" enabled and STIBP protection for hyperthreading
enabled.
"Mitigation: untrained return thunk; SMT vulnerable"
AMD mitigation "untrained return thunk" enabled, on systems with hyperthreading
still vulnerable for attackers on the same CPU core.
"Mitigation: IBPB"
The IBPB (Indirect Branch Prediction Barrier) mitigation method is enabled.
"Mitigation: IBRS"
Selected IBRS mitigation to mitigate RETBLEED. While for Spectre Variant 2 this
mitigation originally was replaced by retpoline, it needs to be reenabled as
a RETBLEED mitigation.
"Mitigation: Enhanced IBRS"
Selected Enhanced IBRS mitigation instead of IBRS to lessen performance impact.
On Arm CPUs the mitigations for Spectre v2 are also mitigating RETBLEED.
Please note that unlike the upstream kernel, SUSE Linux Enterprise 15 SP3 and older code streams do not implement the "retbleed=off" kernel parameter. That means that the mitigation cannot be completely disabled.
rebleed=unret - the default one - and retbleed=ibpb - a more expensive mitigation alternative on AMD - are still supported like upstream.
In general, we strongly discourage disabling all HW-specific mitigations but if there is a need to disable the most expensive part of the Retbleed mitigation (IBRS) on Skylake-based CPUs then this can be achieved by supplying spectre_v2=off on the kernel command line which also disables other Spectre v2 mitigations, including the retbleed one on affected Intel CPUs.
With that, only the "return thunks" are enabled unconditionally but according to our internal testing the overhead should be quite minimal at around 1%.
If you have a business case which cannot operate with that additional overhead and explicitly avoids all mitigations (by mitigations=off with all due consequences) then please open a support ticket or bug entry in the SUSE bugzilla.
Status
Additional Information
References:
- https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00707.html- https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00702.html
-https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1037
-https://developer.arm.com/documentation/ka005138/latest
- https://www.suse.com/security/cve/CVE-2022-29900
- https://www.suse.com/security/cve/CVE-2022-29901
- https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/return-stack-buffer-underflow.html
Disclaimer
This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.
- Document ID:000020693
- Creation Date: 08-Nov-2022
- Modified Date:08-Nov-2022
-
- SUSE Linux Enterprise Desktop
- SUSE Linux Enterprise Server
- SUSE Linux Enterprise Server for SAP Applications
- SUSE Linux Enterprise Micro
- SUSE Linux Enterprise HPC
For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback[at]suse.com
