Commit 6f5bf947 authored by Linus Torvalds's avatar Linus Torvalds
Browse files

Merge tag 'its-for-linus-20250509' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip 

Pull x86 ITS mitigation from Dave Hansen:
 "Mitigate Indirect Target Selection (ITS) issue.

  I'd describe this one as a good old CPU bug where the behavior is
  _obviously_ wrong, but since it just results in bad predictions it
  wasn't wrong enough to notice. Well, the researchers noticed and also
  realized that thus bug undermined a bunch of existing indirect branch
  mitigations.

  Thus the unusually wide impact on this one. Details:

  ITS is a bug in some Intel CPUs that affects indirect branches
  including RETs in the first half of a cacheline. Due to ITS such
  branches may get wrongly predicted to a target of (direct or indirect)
  branch that is located in the second half of a cacheline. Researchers
  at VUSec found this behavior and reported to Intel.

  Affected processors:

   - Cascade Lake, Cooper Lake, Whiskey Lake V, Coffee Lake R, Comet
     Lake, Ice Lake, Tiger Lake and Rocket Lake.

  Scope of impact:

   - Guest/host isolation:

     When eIBRS is used for guest/host isolation, the indirect branches
     in the VMM may still be predicted with targets corresponding to
     direct branches in the guest.

   - Intra-mode using cBPF:

     cBPF can be used to poison the branch history to exploit ITS.
     Realigning the indirect branches and RETs mitigates this attack
     vector.

   - User/kernel:

     With eIBRS enabled user/kernel isolation is *not* impacted by ITS.

   - Indirect Branch Prediction Barrier (IBPB):

     Due to this bug indirect branches may be predicted with targets
     corresponding to direct branches which were executed prior to IBPB.
     This will be fixed in the microcode.

  Mitigation:

  As indirect branches in the first half of cacheline are affected, the
  mitigation is to replace those indirect branches with a call to thunk that
  is aligned to the second half of the cacheline.

  RETs that take prediction from RSB are not affected, but they may be
  affected by RSB-underflow condition. So, RETs in the first half of
  cacheline are also patched to a return thunk that executes the RET aligned
  to second half of cacheline"

* tag 'its-for-linus-20250509' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  selftest/x86/bugs: Add selftests for ITS
  x86/its: FineIBT-paranoid vs ITS
  x86/its: Use dynamic thunks for indirect branches
  x86/ibt: Keep IBT disabled during alternative patching
  mm/execmem: Unify early execmem_cache behaviour
  x86/its: Align RETs in BHB clear sequence to avoid thunking
  x86/its: Add support for RSB stuffing mitigation
  x86/its: Add "vmexit" option to skip mitigation on some CPUs
  x86/its: Enable Indirect Target Selection mitigation
  x86/its: Add support for ITS-safe return thunk
  x86/its: Add support for ITS-safe indirect thunk
  x86/its: Enumerate Indirect Target Selection (ITS) bug
  Documentation: x86/bugs/its: Add ITS documentation
parents caf12fa9 7a9b709e

Documentation/ABI/testing/sysfs-devices-system-cpu

+1 −0
Original line number Diff line number Diff line
@@ -511,6 +511,7 @@ Description: information about CPUs heterogeneity. 


What:		/sys/devices/system/cpu/vulnerabilities

		/sys/devices/system/cpu/vulnerabilities/gather_data_sampling

		/sys/devices/system/cpu/vulnerabilities/indirect_target_selection

		/sys/devices/system/cpu/vulnerabilities/itlb_multihit

		/sys/devices/system/cpu/vulnerabilities/l1tf

		/sys/devices/system/cpu/vulnerabilities/mds

Documentation/admin-guide/hw-vuln/index.rst

+1 −0
Original line number Diff line number Diff line
@@ -23,3 +23,4 @@ are configurable at compile, boot or run time. 
   gather_data_sampling

   reg-file-data-sampling

   rsb

   indirect-target-selection

Documentation/admin-guide/hw-vuln/indirect-target-selection.rst

0 → 100644
+168 −0
Original line number Diff line number Diff line 
.. 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

Documentation/admin-guide/kernel-parameters.txt

+18 −0
Original line number Diff line number Diff line
@@ -2202,6 +2202,23 @@ 
			different crypto accelerators. This option can be used

			to achieve best performance for particular HW.



	indirect_target_selection= [X86,Intel] Mitigation control for Indirect

			Target Selection(ITS) bug in Intel CPUs. Updated

			microcode is also required for a fix in IBPB.



			on:     Enable mitigation (default).

			off:    Disable mitigation.

			force:	Force the ITS bug and deploy default

				mitigation.

			vmexit: Only deploy mitigation if CPU is affected by

				guest/host isolation part of ITS.

			stuff:	Deploy RSB-fill mitigation when retpoline is

				also deployed. Otherwise, deploy the default

				mitigation.



			For details see:

			Documentation/admin-guide/hw-vuln/indirect-target-selection.rst



	init=		[KNL]

			Format: <full_path>

			Run specified binary instead of /sbin/init as init
@@ -3693,6 +3710,7 @@ 
				expose users to several CPU vulnerabilities.

				Equivalent to: if nokaslr then kpti=0 [ARM64]

					       gather_data_sampling=off [X86]

					       indirect_target_selection=off [X86]

					       kvm.nx_huge_pages=off [X86]

					       l1tf=off [X86]

					       mds=off [X86]

arch/x86/Kconfig

+12 −0
Original line number Diff line number Diff line
@@ -2711,6 +2711,18 @@ config MITIGATION_SSB 
	  of speculative execution in a similar way to the Meltdown and Spectre

	  security vulnerabilities.



config MITIGATION_ITS

	bool "Enable Indirect Target Selection mitigation"

	depends on CPU_SUP_INTEL && X86_64

	depends on MITIGATION_RETPOLINE && MITIGATION_RETHUNK

	select EXECMEM

	default y

	help

	  Enable Indirect Target Selection (ITS) mitigation. ITS is a bug in

	  BPU on some Intel CPUs that may allow Spectre V2 style attacks. If

	  disabled, mitigation cannot be enabled via cmdline.

	  See <file:Documentation/admin-guide/hw-vuln/indirect-target-selection.rst>



endif



config ARCH_HAS_ADD_PAGES