.. SPDX-License-Identifier: GPL-2.0 Indirect Target Selection (ITS) =============================== ITS is a vulnerability in some Intel CPUs that support Enhanced IBRS and were released before Alder Lake. ITS may allow an attacker to control the prediction of indirect branches and RETs located in the lower half of a cacheline. ITS is assigned CVE-2024-28956 with a CVSS score of 4.7 (Medium). Scope of Impact --------------- - **eIBRS Guest/Host Isolation**: Indirect branches in KVM/kernel may still be predicted with unintended target corresponding to a branch in the guest. - **Intra-Mode BTI**: In-kernel training such as through cBPF or other native gadgets. - **Indirect Branch Prediction Barrier (IBPB)**: After an IBPB, indirect branches may still be predicted with targets corresponding to direct branches executed prior to the IBPB. This is fixed by the IPU 2025.1 microcode, which should be available via distro updates. Alternatively microcode can be obtained from Intel's github repository [#f1]_. Affected CPUs ------------- Below is the list of ITS affected CPUs [#f2]_ [#f3]_: ======================== ============ ==================== =============== Common name Family_Model eIBRS Intra-mode BTI Guest/Host Isolation ======================== ============ ==================== =============== SKYLAKE_X (step >= 6) 06_55H Affected Affected ICELAKE_X 06_6AH Not affected Affected ICELAKE_D 06_6CH Not affected Affected ICELAKE_L 06_7EH Not affected Affected TIGERLAKE_L 06_8CH Not affected Affected TIGERLAKE 06_8DH Not affected Affected KABYLAKE_L (step >= 12) 06_8EH Affected Affected KABYLAKE (step >= 13) 06_9EH Affected Affected COMETLAKE 06_A5H Affected Affected COMETLAKE_L 06_A6H Affected Affected ROCKETLAKE 06_A7H Not affected Affected ======================== ============ ==================== =============== - All affected CPUs enumerate Enhanced IBRS feature. - IBPB isolation is affected on all ITS affected CPUs, and need a microcode update for mitigation. - None of the affected CPUs enumerate BHI_CTRL which was introduced in Golden Cove (Alder Lake and Sapphire Rapids). This can help guests to determine the host's affected status. - Intel Atom CPUs are not affected by ITS. Mitigation ---------- As only the indirect branches and RETs that have their last byte of instruction in the lower half of the cacheline are vulnerable to ITS, the basic idea behind the mitigation is to not allow indirect branches in the lower half. This is achieved by relying on existing retpoline support in the kernel, and in compilers. ITS-vulnerable retpoline sites are runtime patched to point to newly added ITS-safe thunks. These safe thunks consists of indirect branch in the second half of the cacheline. Not all retpoline sites are patched to thunks, if a retpoline site is evaluated to be ITS-safe, it is replaced with an inline indirect branch. Dynamic thunks ~~~~~~~~~~~~~~ From a dynamically allocated pool of safe-thunks, each vulnerable site is replaced with a new thunk, such that they get a unique address. This could improve the branch prediction accuracy. Also, it is a defense-in-depth measure against aliasing. Note, for simplicity, indirect branches in eBPF programs are always replaced with a jump to a static thunk in __x86_indirect_its_thunk_array. If required, in future this can be changed to use dynamic thunks. All vulnerable RETs are replaced with a static thunk, they do not use dynamic thunks. This is because RETs get their prediction from RSB mostly that does not depend on source address. RETs that underflow RSB may benefit from dynamic thunks. But, RETs significantly outnumber indirect branches, and any benefit from a unique source address could be outweighed by the increased icache footprint and iTLB pressure. Retpoline ~~~~~~~~~ Retpoline sequence also mitigates ITS-unsafe indirect branches. For this reason, when retpoline is enabled, ITS mitigation only relocates the RETs to safe thunks. Unless user requested the RSB-stuffing mitigation. RSB Stuffing ~~~~~~~~~~~~ RSB-stuffing via Call Depth Tracking is a mitigation for Retbleed RSB-underflow attacks. And it also mitigates RETs that are vulnerable to ITS. Mitigation in guests ^^^^^^^^^^^^^^^^^^^^ All guests deploy ITS mitigation by default, irrespective of eIBRS enumeration and Family/Model of the guest. This is because eIBRS feature could be hidden from a guest. One exception to this is when a guest enumerates BHI_DIS_S, which indicates that the guest is running on an unaffected host. To prevent guests from unnecessarily deploying the mitigation on unaffected platforms, Intel has defined ITS_NO bit(62) in MSR IA32_ARCH_CAPABILITIES. When a guest sees this bit set, it should not enumerate the ITS bug. Note, this bit is not set by any hardware, but is **intended for VMMs to synthesize** it for guests as per the host's affected status. Mitigation options ^^^^^^^^^^^^^^^^^^ The ITS mitigation can be controlled using the "indirect_target_selection" kernel parameter. The available options are: ======== =================================================================== on (default) Deploy the "Aligned branch/return thunks" mitigation. If spectre_v2 mitigation enables retpoline, aligned-thunks are only deployed for the affected RET instructions. Retpoline mitigates indirect branches. off Disable ITS mitigation. vmexit Equivalent to "=on" if the CPU is affected by guest/host isolation part of ITS. Otherwise, mitigation is not deployed. This option is useful when host userspace is not in the threat model, and only attacks from guest to host are considered. stuff Deploy RSB-fill mitigation when retpoline is also deployed. Otherwise, deploy the default mitigation. When retpoline mitigation is enabled, RSB-stuffing via Call-Depth-Tracking also mitigates ITS. force Force the ITS bug and deploy the default mitigation. ======== =================================================================== Sysfs reporting --------------- The sysfs file showing ITS mitigation status is: /sys/devices/system/cpu/vulnerabilities/indirect_target_selection Note, microcode mitigation status is not reported in this file. The possible values in this file are: .. list-table:: * - Not affected - The processor is not vulnerable. * - Vulnerable - System is vulnerable and no mitigation has been applied. * - Vulnerable, KVM: Not affected - System is vulnerable to intra-mode BTI, but not affected by eIBRS guest/host isolation. * - Mitigation: Aligned branch/return thunks - The mitigation is enabled, affected indirect branches and RETs are relocated to safe thunks. * - Mitigation: Retpolines, Stuffing RSB - The mitigation is enabled using retpoline and RSB stuffing. References ---------- .. [#f1] Microcode repository - https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files .. [#f2] Affected Processors list - https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html .. [#f3] Affected Processors list (machine readable) - https://github.com/intel/Intel-affected-processor-list