Xen Security Advisory 456 v2 (CVE-2024-2201) - x86: Native Branch History Injection

[Xen.org security team <security@xxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

            Xen Security Advisory CVE-2024-2201 / XSA-456
                              version 2

                 x86: Native Branch History Injection

UPDATES IN VERSION 2
====================

Public release.

ISSUE DESCRIPTION
=================

In August 2022, researchers at VU Amsterdam disclosed Spectre-BHB.

Spectre-BHB was discussed in XSA-398.  At the time, the susceptibility
of Xen to Spectre-BHB was uncertain so no specific action was taken in
XSA-398.  However, various changes were made thereafter in upstream Xen
as a consequence; more on these later.

VU Amsterdam have subsequently adjusted the attack to be pulled off
entirely from userspace, without the aid of a managed runtime in the
victim context.

For more details, see:
  https://vusec.net/projects/native-bhi
  https://vusec.net/projects/bhi-spectre-bhb
  
https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/branch-history-injection.html
  https://xenbits.xen.org/xsa/advisory-398.html

IMPACT
======

An attacker might be able to infer the contents of arbitrary host
memory, including memory assigned to other guests.

VULNERABLE SYSTEMS
==================

Systems running all versions of Xen are affected.

Only Intel x86 CPUs are potentially affected.  CPUs from other
manufacturers are not known to be affected.

A wide range of Intel CPUs employ Branch History prediction techniques.
However for older CPUs existing Spectre-v2 mitigations (XSA-254) are
believed to be sufficient to mitigate Native-BHI.

Therefore, the rest of the discussion will be limited in scope to the
CPUs for which a change in behaviour is expected.  These are believed to
be all CPUs with eIBRS (Enhanced IBRS, a.k.a. IBRS_ALL or IBRS_ATT).
eIBRS signifies a hardware adjustment (mode-tagged indirect predictions)
designed to combat Spectre-v2, available in CPUs from 2019 onwards.

To determine if a system has eIBRS, run `xen-cpuid -v` in dom0, looking for
the string "eibrs" in the Dynamic Raw block of information.  e.g.

  # xen-cpuid -v
  ...
  Dynamic sets:
  Raw                             ...
    ...
    [16] MSR_ARCH_CAPS.lo         ... eibrs ...
    ...
  ...

Be aware that the Static sets are compile time information so will include the
string "eibrs" irrespective of hardware support.  If there is no row for "[16]
MSR_ARCH_CAPS.lo" then the fixes for XSA-435 are missing.

MITIGATION
==========

There are no mitigations.

CREDITS
=======

This issue was discovered by VU Amsterdam.

RESOLUTION
==========

In Xen 4.17, in response to the original Spectre-BHB, CET-IBT support was
added to Xen to use on capable hardware.  It also came with work to remove
unnecessary function pointers, and to de-virtualise function pointers at boot,
as both a performance and hardening improvement.  This work has been steadily
continuing since, and every removed/de-virtualised function pointer reduces
the options available to an adversary trying to mount a Native-BHI attack.
All of this work has been backported to 4.17 and later for this advisory.

Beginning with the Intel Alder Lake (Client) and Sapphire Rapids (Server)
CPUs, a hardware control called BHI_DIS_S is available, which restricts
history-based predictions.  This control requires updated microcode on some
CPUs.  Look for "bhi-ctrl" in `xen-cpuid -v`, similar to eibrs above.

Xen has been updated to use this control when available, and to virtualise it
for guests to use.

For CPUs without BHI_DIS_S, BHB clearing sequences need using.  Out of an
abundance of caution, all sequences in the Intel whitepaper have been
implemented, although Xen will only use the "short" sequence by default.  The
others are available to opt in to.

The work to mitigate Native-BHI is extensive, and the backports are
more-extensive still.

Therefore, we have decided to produce new releases on all stable trees.
Please find fixes in the respective branches under the following release
tags:

  RELEASE-4.18.2
  RELEASE-4.17.4
  RELEASE-4.16.6
  RELEASE-4.15.6

Other release activities (tarballs, announcements, etc) will happen in
due course.

DEPLOYMENT DURING EMBARGO
=========================

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.

(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmYVdY4MHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZNk0IAMWbhl7mAn9QN5pG9rl36Vc/I3JKW5L0Tk4WAlMH
edpuYbd6epNofksphsSmpEf2clYqtDs/7Rcy138YlyfEoE5JVTWcN/RgXqJ3/W84
bzkLb1qY1U8muyQpa0jmo9DXM1Yb20ejVUSf2s290ninuhmy7HsZpl/Gnwj+zV0R
zhR1dgGMvnqzj4b+7XAi5n9Y0vFWoAN+fsMCx4Ml0yPM8yIOJSswDfGmzgc/KKMV
Wq+li52y+qpqACuODTDq7NQAZIE8biwkxrUC9kg9N9q2jsAJbEFwnNLrOHT8UA+9
pDIcuR7aF4hTDaqK31mD2cdXosBkWprcPQgyM/4mpTKuu+I=
=M1Pd
-----END PGP SIGNATURE-----