Information

Files

Advisory

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

            Xen Security Advisory CVE-2022-23824 / XSA-422
                               version 2

               x86: Multiple speculative security issues

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

Change the URL referenced for the Branch Type Confusion update.

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

1) Researchers have discovered that on some AMD CPUs, the implementation
   of IBPB (Indirect Branch Prediction Barrier) does not behave
   according to the specification.

   Specifically, IBPB fails to properly flush the RAS (Return Address
   Stack, also RSB - Return Stack Buffer - in Intel terminology; one of
   the hardware prediction structures), allowing attacker controlled
   values to survive across a deliberate attempt to purge said values.

   AMD have allocated CVE-2022-23824.

   For more details, see:
     https://www.amd.com/en/corporate/product-security/bulletin/amd-sb-1040


2) AMD have discovered that under some circumstances, the previous
   reported information about Branch Type Confusion (XSA-407 /
   CVE-2022-23825) was inaccurate.

   Specifically, it was previously reported that the small speculation
   window was not long enough to contain two dependent loads.  It has
   turned out not to be true, and in some circumstances, the speculation
   window is long enough to contain two dependent loads.

   AMD have not allocated a new CVE for this issue.

   For more details, see:
     https://www.amd.com/system/files/documents/technical-guidance-for-mitigating-branch-type-confusion.pdf

IMPACT
======

An attacker might be able to infer the contents of memory belonging to
other guests.

Due to the interaction of this issue with previous speculation fixes in
their default configuration, an attacker cannot leverage this
vulnerability to infer the content of memory that belongs to Xen itself.

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

Systems running all versions of Xen are affected.

Only AMD CPUs are potentially vulnerable.  CPUs from other hardware
vendors are not impacted.

Whether a CPU is potentially vulnerable depends on its
microarchitecture.  Consult your hardware vendor.

The fix for XSA-407 / CVE-2022-23825 elected, out of an abundance of
caution, to use IBPB-on-entry as a Branch Type Confusion mitigation.  It
is believed that this mitigation is still sufficient, in light of the
new discoveries.  Therefore, no changes are being provided at this time.

For CVE-2022-23824, patches are being provided on all releases as the
bug pertains to a specific speculation control not working as
documented, but there are a number circumstances where safety is
provided as a side effect of other speculative mitigations.

 * The issue is that IBPB doesn't flush the RAS (Return Address Stack).
   Also called the RSB (Return Stack Buffer) in Intel terminology.  Xen
   tends to follow Intel's terminology.

 * By default, Xen uses IBPB on a context switch from one vCPU to
   another vCPU to prevent guest to guest attacks.  This action is not
   about protecting Xen from a malicious guest; such protections are
   elsewhere.

 * By default, Xen flushes the RAS/RSB on VMExit from HVM/PVH vCPUs, in
   order to protect itself from a malicious vCPU.  Therefore, a
   malicious HVM/PVH guest cannot mount an attack using this
   vulnerability.

 * Whether Xen flushes the RAS/RSB by default on exit from PV vCPUs
   (again, to protect itself) is more complicated.  There is an
   optimisation commonly used by native OSes when the SMEP (Supervisor
   Mode Execution Prevention) feature is active, which Xen can make use
   in some cases.

   - Xen 4.15 and older flush the RAS/RSB by default.

   - Xen 4.16 introduced an optimisation to skip flushing the RAS/RSB
     when safe.  For CPUs impacted by CVE-2022-23824, this comes down to
     whether 32-bit PV guest support is enabled or not; *irrespective*
     of whether any 32-bit PV guests are actively running.

     If Xen is built with CONFIG_PV32=n, or Xen is booted with
     `pv=no-32`, or 32-bit PV guests are disabled as a side effect of
     CET being active (requires a capable toolchain, CONFIG_XEN_SHSTK=y
     or CONFIG_XEN_IBT=y, and capable hardware), then Xen will by
     default use the performance optimisation.  In this case, a
     malicious 64-bit PV guest can mount an attack using this issue.

Note: This analysis is only applicable for systems which are fully up to
date with previous speculation-related XSAs, and have not used
`spec-ctrl=` on the Xen command line to tune the speculative
mitigations.

MITIGATION
==========

If there are untrusted 64-bit PV guests on the system on a Xen 4.16 or
later system, specifying `spec-ctrl=rsb` on Xen's command line and
rebooting will mitigate the vulnerability.

RESOLUTION
==========

Applying the appropriate set of patches resolves this issue.

Note that patches for released versions are generally prepared to
apply to the stable branches, and may not apply cleanly to the most
recent release tarball.  Downstreams are encouraged to update to the
tip of the stable branch before applying these patches.

xsa422/xsa422-?.patch           xen-unstable
xsa422/xsa422-4.16-?.patch      Xen 4.16.x
xsa422/xsa422-4.15-?.patch      Xen 4.15.x
xsa422/xsa422-4.14-?.patch      Xen 4.14.x
xsa422/xsa422-4.13-?.patch      Xen 4.13.x

$ sha256sum xsa422* xsa422*/*
f8722655564736c69b708a24b524fec5d351aff4ea6cc5c87dff3629561945f2  xsa422.meta
c6317d66e60ec8d3c5610646bf0f12f281f000706621804f3c6072d0772fa0bd  xsa422/xsa422-1.patch
aeec164f676ddef2e7736d733a43a239a4cd0005e82c763b0468259891691be9  xsa422/xsa422-2.patch
0e7603b0538914b675c891c4f1a8b4de19c9ae5b03d29c314d4484338a51e780  xsa422/xsa422-4.13-1.patch
5eefa1ce66b80bfb3ac4e14c99c39c73922f5508aad798aeeecdb9e0f25c3054  xsa422/xsa422-4.13-2.patch
2051142f1131452b5ca2166736866ddc1bf06910f063cdbc3997c89f31db2760  xsa422/xsa422-4.14-1.patch
821764468805547650ce3699ee37fd14083ea70958908d31905adf5ca32302ed  xsa422/xsa422-4.14-2.patch
148ec57f7c4970c2d33891a8080ef643d76d1eafa9ca77ac45a1fc1416002cf8  xsa422/xsa422-4.15-1.patch
96e5d7243438bb16aa5b3528136c06f09f18e6ac4a52230d20f9db49a85922a0  xsa422/xsa422-4.15-2.patch
f02b62f32d4910ecbe3946722a5f46d65db080e2007823c5bfa5c365d243e45f  xsa422/xsa422-4.16-1.patch
ba3547df8576433da0b5978e3def70d9804d2ed0847ad58914b78715868657c5  xsa422/xsa422-4.16-2.patch
$
-----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmNtFQQMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZmA4H/ieQkCh/8nKgXCr/82WPtzmN5Ia0PM1AllHtap/B
1+Vap2hJlz0fmsVPvTjUvw4VkGdS9YCiXVc4pZv7PrzWFFqhgZSDEudoDZVw5RgS
t3Wnk7+VIqqQ3UFaCskRw1fS3P1YrEVTB8zQKFosQxN986+zCpsBWfpf+tnrVHgi
l/GL2/Pfvm6qRbXKGZxb4gHWSSzdzWRJQTL+zVIlNwpdwGNoXFiu1eZPi7IN/ILP
craqr4jpqfgKHeRSw/1TE7kyoKubqzRB9fOjaJDE4lMZvgACKbDEiKlUCd5xrtBN
W0VsCS7Oc9HvgJpZH0H7iVANl2PCDu3ujq7vfG3Ey0xMMmI=
=qd57
-----END PGP SIGNATURE-----