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-08-06 16:29:24 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Comparing /work/SRC/openSUSE:Factory/xen (Old) and /work/SRC/openSUSE:Factory/.xen.new.22712 (New) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Package is "xen" Sun Aug 6 16:29:24 2023 rev:334 rq:1102421 version:4.17.1_06 Changes: -------- --- /work/SRC/openSUSE:Factory/xen/xen.changes 2023-07-09 20:42:51.694040301 +0200 +++ /work/SRC/openSUSE:Factory/.xen.new.22712/xen.changes 2023-08-06 16:29:30.279675762 +0200 @@ -1,0 +2,14 @@ +Fri Jul 28 15:15:15 UTC 2023 - oher...@suse.de + +- Add more debug to libxc-sr-track-migration-time.patch + This is supposed to help with doing the math in case xl restore + fails with ERANGE as reported in bug#1209311 + +------------------------------------------------------------------- +Tue Jul 25 10:44:08 MDT 2023 - carn...@suse.com + +- bsc#1213616 - VUL-0: CVE-2023-20593: xen: x86/AMD: Zenbleed + (XSA-433) + 64bea1b2-x86-AMD-Zenbleed.patch + +------------------------------------------------------------------- New: ---- 64bea1b2-x86-AMD-Zenbleed.patch ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Other differences: ------------------ ++++++ xen.spec ++++++ --- /var/tmp/diff_new_pack.KPhJ4Z/_old 2023-08-06 16:29:31.775685344 +0200 +++ /var/tmp/diff_new_pack.KPhJ4Z/_new 2023-08-06 16:29:31.779685370 +0200 @@ -165,6 +165,7 @@ Patch8: 646b782b-PCI-pci_get_pdev-respect-segment.patch Patch9: 647dfb0e-x86-missing-unlock-in-microcode_update_helper.patch Patch10: 648863fc-AMD-IOMMU-Invalidate-All-check.patch +Patch11: 64bea1b2-x86-AMD-Zenbleed.patch # EMBARGOED security fixes # libxc Patch301: libxc-bitmap-long.patch ++++++ 64bea1b2-x86-AMD-Zenbleed.patch ++++++ # Commit f91c5ea970675637721bb7f18adaa189837eb783 # Date 2023-07-24 17:07:14 +0100 # Author Andrew Cooper <andrew.coop...@citrix.com> # Committer Andrew Cooper <andrew.coop...@citrix.com> x86/amd: Mitigations for Zenbleed Zenbleed is a malfunction on AMD Zen2 uarch parts which results in corruption of the vector registers. An attacker can trigger this bug deliberately in order to access stale data in the physical vector register file. This can include data from sibling threads, or a higher-privilege context. Microcode is the preferred mitigation but in the case that's not available use the chickenbit as instructed by AMD. Re-evaluate the mitigation on late microcode load too. This is XSA-433 / CVE-2023-20593. Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> Acked-by: Roger Pau Monné <roger....@citrix.com> --- a/xen/arch/x86/cpu/amd.c +++ b/xen/arch/x86/cpu/amd.c @@ -13,6 +13,7 @@ #include <asm/spec_ctrl.h> #include <asm/acpi.h> #include <asm/apic.h> +#include <asm/microcode.h> #include "cpu.h" @@ -878,6 +879,72 @@ void __init detect_zen2_null_seg_behavio } +void amd_check_zenbleed(void) +{ + const struct cpu_signature *sig = &this_cpu(cpu_sig); + unsigned int good_rev, chickenbit = (1 << 9); + uint64_t val, old_val; + + /* + * If we're virtualised, we can't do family/model checks safely, and + * we likely wouldn't have access to DE_CFG even if we could see a + * microcode revision. + * + * A hypervisor may hide AVX as a stopgap mitigation. We're not in a + * position to care either way. An admin doesn't want to be disabling + * AVX as a mitigation on any build of Xen with this logic present. + */ + if (cpu_has_hypervisor || boot_cpu_data.x86 != 0x17) + return; + + switch (boot_cpu_data.x86_model) { + case 0x30 ... 0x3f: good_rev = 0x0830107a; break; + case 0x60 ... 0x67: good_rev = 0x0860010b; break; + case 0x68 ... 0x6f: good_rev = 0x08608105; break; + case 0x70 ... 0x7f: good_rev = 0x08701032; break; + case 0xa0 ... 0xaf: good_rev = 0x08a00008; break; + default: + /* + * With the Fam17h check above, parts getting here are Zen1. + * They're not affected. + */ + return; + } + + rdmsrl(MSR_AMD64_DE_CFG, val); + old_val = val; + + /* + * Microcode is the preferred mitigation, in terms of performance. + * However, without microcode, this chickenbit (specific to the Zen2 + * uarch) disables Floating Point Mov-Elimination to mitigate the + * issue. + */ + val &= ~chickenbit; + if (sig->rev < good_rev) + val |= chickenbit; + + if (val == old_val) + /* Nothing to change. */ + return; + + /* + * DE_CFG is a Core-scoped MSR, and this write is racy during late + * microcode load. However, both threads calculate the new value from + * state which is shared, and unrelated to the old value, so the + * result should be consistent. + */ + wrmsrl(MSR_AMD64_DE_CFG, val); + + /* + * Inform the admin that we changed something, but don't spam, + * especially during a late microcode load. + */ + if (smp_processor_id() == 0) + printk(XENLOG_INFO "Zenbleed mitigation - using %s\n", + val & chickenbit ? "chickenbit" : "microcode"); +} + static void cf_check init_amd(struct cpuinfo_x86 *c) { u32 l, h; @@ -1150,6 +1217,8 @@ static void cf_check init_amd(struct cpu if ((smp_processor_id() == 1) && !cpu_has(c, X86_FEATURE_ITSC)) disable_c1_ramping(); + amd_check_zenbleed(); + check_syscfg_dram_mod_en(); amd_log_freq(c); --- a/xen/arch/x86/cpu/microcode/amd.c +++ b/xen/arch/x86/cpu/microcode/amd.c @@ -262,6 +262,8 @@ static int cf_check apply_microcode(cons "microcode: CPU%u updated from revision %#x to %#x, date = %04x-%02x-%02x\n", cpu, old_rev, rev, patch->year, patch->month, patch->day); + amd_check_zenbleed(); + return 0; } --- a/xen/arch/x86/include/asm/processor.h +++ b/xen/arch/x86/include/asm/processor.h @@ -637,6 +637,8 @@ enum ap_boot_method { }; extern enum ap_boot_method ap_boot_method; +void amd_check_zenbleed(void); + #endif /* !__ASSEMBLY__ */ #endif /* __ASM_X86_PROCESSOR_H */ ++++++ libxc-sr-track-migration-time.patch ++++++ --- /var/tmp/diff_new_pack.KPhJ4Z/_old 2023-08-06 16:29:31.967686574 +0200 +++ /var/tmp/diff_new_pack.KPhJ4Z/_new 2023-08-06 16:29:31.971686600 +0200 @@ -181,11 +181,12 @@ uint32_t type; --- a/tools/libs/guest/xg_sr_restore.c +++ b/tools/libs/guest/xg_sr_restore.c -@@ -884,6 +884,7 @@ static int restore(struct xc_sr_context +@@ -884,6 +884,8 @@ static int restore(struct xc_sr_context struct xc_sr_rhdr rhdr; int rc, saved_rc = 0, saved_errno = 0; + SUSEINFO("domid %u: %s %s start", ctx->domid, ctx->uuid, __func__); ++ DPRINTF("domid %u: max_pages %lx tot_pages %lx p2m_size %lx", ctx->domid, ctx->restore.max_pages, ctx->restore.tot_pages, ctx->restore.p2m_size); IPRINTF("Restoring domain"); rc = setup(ctx);