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