xref: /linux/Documentation/admin-guide/hw-vuln/indirect-target-selection.rst (revision 6f5bf947bab06f37ff931c359fd5770c4d9cbf87)

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