Script 'mail_helper' called by obssrc
Hello community,
here is the log from the commit of package xen for openSUSE:Factory checked in
at 2023-05-26 20:15:25
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Comparing /work/SRC/openSUSE:Factory/xen (Old)
and /work/SRC/openSUSE:Factory/.xen.new.1533 (New)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "xen"
Fri May 26 20:15:25 2023 rev:332 rq:1089051 version:4.17.1_04
Changes:
--------
--- /work/SRC/openSUSE:Factory/xen/xen.changes 2023-05-09 13:08:17.165359616
+0200
+++ /work/SRC/openSUSE:Factory/.xen.new.1533/xen.changes 2023-05-26
20:15:37.788318570 +0200
@@ -1,0 +2,7 @@
+Mon May 22 07:52:57 MDT 2023 - carn...@suse.com
+
+- bsc#1211433 - VUL-0: CVE-2022-42336: xen: Mishandling of guest
+ SSBD selection on AMD hardware (XSA-431)
+ 64639e84-amd-fix-legacy-setting-of-SSBD-on-AMD-Family-17h.patch
+
+-------------------------------------------------------------------
New:
----
64639e84-amd-fix-legacy-setting-of-SSBD-on-AMD-Family-17h.patch
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Other differences:
------------------
++++++ xen.spec ++++++
--- /var/tmp/diff_new_pack.cTk9Zo/_old 2023-05-26 20:15:38.928325365 +0200
+++ /var/tmp/diff_new_pack.cTk9Zo/_new 2023-05-26 20:15:38.936325413 +0200
@@ -119,7 +119,7 @@
%endif
Provides: installhint(reboot-needed)
-Version: 4.17.1_02
+Version: 4.17.1_04
Release: 0
Summary: Xen Virtualization: Hypervisor (aka VMM aka Microkernel)
License: GPL-2.0-only
@@ -160,6 +160,7 @@
Patch3: 643e387f-xen-update-CONFIG_DEBUG_INFO-help-text.patch
Patch4: 6447a8fd-x86-EFI-permit-crash-dump-analysis.patch
Patch5: 64525c61-tools-libs-guest-assist-gcc13s-realloc-analyzer.patch
+Patch6: 64639e84-amd-fix-legacy-setting-of-SSBD-on-AMD-Family-17h.patch
# EMBARGOED security fixes
# libxc
Patch301: libxc-bitmap-long.patch
++++++ 64639e84-amd-fix-legacy-setting-of-SSBD-on-AMD-Family-17h.patch ++++++
Subject: x86/amd: fix legacy setting of SSBD on AMD Family 17h
From: Roger Pau Monné roger....@citrix.com Tue May 16 17:22:35 2023 +0200
Date: Tue May 16 17:22:35 2023 +0200:
Git: 66c930ceac3989b6dc6031bfc30e1e894fc6aebe
The current logic to set SSBD on AMD Family 17h and Hygon Family 18h
processors requires that the setting of SSBD is coordinated at a core
level, as the setting is shared between threads. Logic was introduced
to keep track of how many threads require SSBD active in order to
coordinate it, such logic relies on using a per-core counter of
threads that have SSBD active.
Given the current logic, it's possible for a guest to under or
overflow the thread counter, because each write to VIRT_SPEC_CTRL.SSBD
by the guest gets propagated to the helper that does the per-core
active accounting. Overflowing the counter is not so much of an
issue, as this would just make SSBD sticky.
Underflowing however is more problematic: on non-debug Xen builds a
guest can perform empty writes to VIRT_SPEC_CTRL that would cause the
counter to underflow and thus the value gets saturated to the max
value of unsigned int. At which points attempts from any thread to
set VIRT_SPEC_CTRL.SSBD won't get propagated to the hardware anymore,
because the logic will see that the counter is greater than 1 and
assume that SSBD is already active, effectively loosing the setting
of SSBD and the protection it provides.
Fix this by introducing a per-CPU variable that keeps track of whether
the current thread has legacy SSBD active or not, and thus only
attempt to propagate the value to the hardware once the thread
selected value changes.
This is XSA-431 / CVE-2022-42336
Fixes: b2030e6730a2 ('amd/virt_ssbd: set SSBD at vCPU context switch')
Reported-by: Andrew Cooper <andrew.coop...@citrix.com>
Signed-off-by: Roger Pau Monné <roger....@citrix.com>
Reviewed-by: Jan Beulich <jbeul...@suse.com>
master commit: eda98ea870803ea204a1928519b3f21ec6a679b6
master date: 2023-05-16 17:17:24 +0200
diff --git a/xen/arch/x86/cpu/amd.c b/xen/arch/x86/cpu/amd.c
index 1ddb55cbe5..b6a20d375a 100644
--- a/xen/arch/x86/cpu/amd.c
+++ b/xen/arch/x86/cpu/amd.c
@@ -783,12 +783,23 @@ bool __init amd_setup_legacy_ssbd(void)
return true;
}
+/*
+ * legacy_ssbd is always initialized to false because when SSBD is set
+ * from the command line guest attempts to change it are a no-op (see
+ * amd_set_legacy_ssbd()), whereas when SSBD is inactive hardware will
+ * be forced into that mode (see amd_init_ssbd()).
+ */
+static DEFINE_PER_CPU(bool, legacy_ssbd);
+
+/* Must be called only when the SSBD setting needs toggling. */
static void core_set_legacy_ssbd(bool enable)
{
const struct cpuinfo_x86 *c = ¤t_cpu_data;
struct ssbd_ls_cfg *status;
unsigned long flags;
+ BUG_ON(this_cpu(legacy_ssbd) == enable);
+
if ((c->x86 != 0x17 && c->x86 != 0x18) || c->x86_num_siblings <= 1) {
BUG_ON(!set_legacy_ssbd(c, enable));
return;
@@ -816,12 +827,17 @@ void amd_set_legacy_ssbd(bool enable)
*/
return;
+ if (this_cpu(legacy_ssbd) == enable)
+ return;
+
if (cpu_has_virt_ssbd)
wrmsr(MSR_VIRT_SPEC_CTRL, enable ? SPEC_CTRL_SSBD : 0, 0);
else if (amd_legacy_ssbd)
core_set_legacy_ssbd(enable);
else
ASSERT_UNREACHABLE();
+
+ this_cpu(legacy_ssbd) = enable;
}
/*
