pkgsrc-Changes-HG archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
[pkgsrc/trunk]: pkgsrc/sysutils/xenkernel415 Apply patches for Xen security a...
details: https://anonhg.NetBSD.org/pkgsrc/rev/b09d9be17fa4
branches: trunk
changeset: 381031:b09d9be17fa4
user: bouyer <bouyer%pkgsrc.org@localhost>
date: Fri Jun 24 13:07:52 2022 +0000
description:
Apply patches for Xen security advisory 397 up to 402, and 404 (XSA403 still
not released).
Bump PKGREVISION
diffstat:
sysutils/xenkernel415/Makefile | 4 +-
sysutils/xenkernel415/distinfo | 9 +-
sysutils/xenkernel415/patches/patch-XSA397 | 100 +
sysutils/xenkernel415/patches/patch-XSA398 | 120 +
sysutils/xenkernel415/patches/patch-XSA399 | 47 +
sysutils/xenkernel415/patches/patch-XSA400 | 3142 ++++++++++++++++++++++++++++
sysutils/xenkernel415/patches/patch-XSA401 | 363 +++
sysutils/xenkernel415/patches/patch-XSA402 | 773 ++++++
sysutils/xenkernel415/patches/patch-XSA404 | 499 ++++
9 files changed, 5054 insertions(+), 3 deletions(-)
diffs (truncated from 5108 to 300 lines):
diff -r 88b5499bc7bd -r b09d9be17fa4 sysutils/xenkernel415/Makefile
--- a/sysutils/xenkernel415/Makefile Fri Jun 24 12:30:09 2022 +0000
+++ b/sysutils/xenkernel415/Makefile Fri Jun 24 13:07:52 2022 +0000
@@ -1,9 +1,9 @@
-# $NetBSD: Makefile,v 1.5 2022/04/30 00:21:15 khorben Exp $
+# $NetBSD: Makefile,v 1.6 2022/06/24 13:07:52 bouyer Exp $
VERSION= 4.15.2
DISTNAME= xen-${VERSION}
PKGNAME= xenkernel415-${VERSION}
-PKGREVISION= 1
+PKGREVISION= 2
CATEGORIES= sysutils
MASTER_SITES= https://downloads.xenproject.org/release/xen/${VERSION}/
DIST_SUBDIR= xen415
diff -r 88b5499bc7bd -r b09d9be17fa4 sysutils/xenkernel415/distinfo
--- a/sysutils/xenkernel415/distinfo Fri Jun 24 12:30:09 2022 +0000
+++ b/sysutils/xenkernel415/distinfo Fri Jun 24 13:07:52 2022 +0000
@@ -1,9 +1,16 @@
-$NetBSD: distinfo,v 1.5 2022/03/04 17:54:08 bouyer Exp $
+$NetBSD: distinfo,v 1.6 2022/06/24 13:07:52 bouyer Exp $
BLAKE2s (xen415/xen-4.15.2.tar.gz) = f6e3d354a144c9ff49a198ebcafbd5e8a4414690d5672b3e2ed394c461ab8ab0
SHA512 (xen415/xen-4.15.2.tar.gz) = 1cbf988fa8ed38b7ad724978958092ca0e5506e38c709c7d1af196fb8cb8ec0197a79867782761ef230b268624b3d7a0d5d0cd186f37d25f495085c71bf70d54
Size (xen415/xen-4.15.2.tar.gz) = 40773378 bytes
SHA1 (patch-Config.mk) = 9372a09efd05c9fbdbc06f8121e411fcb7c7ba65
+SHA1 (patch-XSA397) = caf9698a8817ae0728da9be6f2018392c9ab6634
+SHA1 (patch-XSA398) = e4fff05675bcf231f9fdf99e9773d1389cd0660c
+SHA1 (patch-XSA399) = c9ab4473654810ca2701dfc38c26e91a0d7f2eb5
+SHA1 (patch-XSA400) = 33d3ae929427ef3e8c74f9e1c36fc1d7e742a8f3
+SHA1 (patch-XSA401) = 8589aa9465c9416b4266beaad37a843de9906add
+SHA1 (patch-XSA402) = 5fe64577fcc249e202591d3a88ab423dbaf0ae42
+SHA1 (patch-XSA404) = ffb441cb248988b679707387e878ad0908082131
SHA1 (patch-xen_Makefile) = 465388d80de414ca3bb84faefa0f52d817e423a6
SHA1 (patch-xen_Rules.mk) = c743dc63f51fc280d529a7d9e08650292c171dac
SHA1 (patch-xen_arch_x86_Kconfig) = df14bfa09b9a0008ca59d53c938d43a644822dd9
diff -r 88b5499bc7bd -r b09d9be17fa4 sysutils/xenkernel415/patches/patch-XSA397
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/sysutils/xenkernel415/patches/patch-XSA397 Fri Jun 24 13:07:52 2022 +0000
@@ -0,0 +1,100 @@
+$NetBSD: patch-XSA397,v 1.1 2022/06/24 13:07:52 bouyer Exp $
+
+From: Roger Pau Monne <roger.pau%citrix.com@localhost>
+Subject: x86/hap: do not switch on log dirty for VRAM tracking
+
+XEN_DMOP_track_dirty_vram possibly calls into paging_log_dirty_enable
+when using HAP mode, and it can interact badly with other ongoing
+paging domctls, as XEN_DMOP_track_dirty_vram is not holding the domctl
+lock.
+
+This was detected as a result of the following assert triggering when
+doing repeated migrations of a HAP HVM domain with a stubdom:
+
+Assertion 'd->arch.paging.log_dirty.allocs == 0' failed at paging.c:198
+----[ Xen-4.17-unstable x86_64 debug=y Not tainted ]----
+CPU: 34
+RIP: e008:[<ffff82d040314b3b>] arch/x86/mm/paging.c#paging_free_log_dirty_bitmap+0x606/0x6
+RFLAGS: 0000000000010206 CONTEXT: hypervisor (d0v23)
+[...]
+Xen call trace:
+ [<ffff82d040314b3b>] R arch/x86/mm/paging.c#paging_free_log_dirty_bitmap+0x606/0x63a
+ [<ffff82d040279f96>] S xsm/flask/hooks.c#domain_has_perm+0x5a/0x67
+ [<ffff82d04031577f>] F paging_domctl+0x251/0xd41
+ [<ffff82d04031640c>] F paging_domctl_continuation+0x19d/0x202
+ [<ffff82d0403202fa>] F pv_hypercall+0x150/0x2a7
+ [<ffff82d0403a729d>] F lstar_enter+0x12d/0x140
+
+Such assert triggered because the stubdom used
+XEN_DMOP_track_dirty_vram while dom0 was in the middle of executing
+XEN_DOMCTL_SHADOW_OP_OFF, and so log dirty become enabled while
+retiring the old structures, thus leading to new entries being
+populated in already clear slots.
+
+Fix this by not enabling log dirty for VRAM tracking, similar to what
+is done when using shadow instead of HAP. Call
+p2m_enable_hardware_log_dirty when enabling VRAM tracking in order to
+get some hardware assistance if available. As a side effect the memory
+pressure on the p2m pool should go down if only VRAM tracking is
+enabled, as the dirty bitmap is no longer allocated.
+
+Note that paging_log_dirty_range (used to get the dirty bitmap for
+VRAM tracking) doesn't use the log dirty bitmap, and instead relies on
+checking whether each gfn on the range has been switched from
+p2m_ram_logdirty to p2m_ram_rw in order to account for dirty pages.
+
+This is CVE-2022-26356 / XSA-397.
+
+Signed-off-by: Roger Pau Monné <roger.pau%citrix.com@localhost>
+Reviewed-by: Jan Beulich <jbeulich%suse.com@localhost>
+
+--- xen/include/asm-x86/paging.h.orig
++++ xen/include/asm-x86/paging.h
+@@ -162,9 +162,6 @@ void paging_log_dirty_range(struct domai
+ unsigned long nr,
+ uint8_t *dirty_bitmap);
+
+-/* enable log dirty */
+-int paging_log_dirty_enable(struct domain *d, bool log_global);
+-
+ /* log dirty initialization */
+ void paging_log_dirty_init(struct domain *d, const struct log_dirty_ops *ops);
+
+--- xen/arch/x86/mm/hap/hap.c.orig
++++ xen/arch/x86/mm/hap/hap.c
+@@ -69,13 +69,6 @@ int hap_track_dirty_vram(struct domain *
+ {
+ unsigned int size = DIV_ROUND_UP(nr_frames, BITS_PER_BYTE);
+
+- if ( !paging_mode_log_dirty(d) )
+- {
+- rc = paging_log_dirty_enable(d, false);
+- if ( rc )
+- goto out;
+- }
+-
+ rc = -ENOMEM;
+ dirty_bitmap = vzalloc(size);
+ if ( !dirty_bitmap )
+@@ -107,6 +100,10 @@ int hap_track_dirty_vram(struct domain *
+
+ paging_unlock(d);
+
++ domain_pause(d);
++ p2m_enable_hardware_log_dirty(d);
++ domain_unpause(d);
++
+ if ( oend > ostart )
+ p2m_change_type_range(d, ostart, oend,
+ p2m_ram_logdirty, p2m_ram_rw);
+--- xen/arch/x86/mm/paging.c.orig
++++ xen/arch/x86/mm/paging.c
+@@ -211,7 +211,7 @@ static int paging_free_log_dirty_bitmap(
+ return rc;
+ }
+
+-int paging_log_dirty_enable(struct domain *d, bool log_global)
++static int paging_log_dirty_enable(struct domain *d, bool log_global)
+ {
+ int ret;
+
diff -r 88b5499bc7bd -r b09d9be17fa4 sysutils/xenkernel415/patches/patch-XSA398
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/sysutils/xenkernel415/patches/patch-XSA398 Fri Jun 24 13:07:52 2022 +0000
@@ -0,0 +1,120 @@
+$NetBSD: patch-XSA398,v 1.1 2022/06/24 13:07:52 bouyer Exp $
+
+From 1b50f41b3bd800eb72064063da0c64b86d629f3a Mon Sep 17 00:00:00 2001
+From: Andrew Cooper <andrew.cooper3%citrix.com@localhost>
+Date: Mon, 7 Mar 2022 16:35:52 +0000
+Subject: x86/spec-ctrl: Cease using thunk=lfence on AMD
+
+AMD have updated their Spectre v2 guidance, and lfence/jmp is no longer
+considered safe. AMD are recommending using retpoline everywhere.
+
+Retpoline is incompatible with CET. All CET-capable hardware has efficient
+IBRS (specifically, not something retrofitted in microcode), so use IBRS (and
+STIBP for consistency sake).
+
+This is a logical change on AMD, but not on Intel as the default calculations
+would end up with these settings anyway. Leave behind a message if IBRS is
+found to be missing.
+
+Also update the default heuristics to never select THUNK_LFENCE. This causes
+AMD CPUs to change their default to retpoline.
+
+Also update the printed message to include the AMD MSR_SPEC_CTRL settings, and
+STIBP now that we set it for consistency sake.
+
+This is part of XSA-398 / CVE-2021-26401.
+
+Signed-off-by: Andrew Cooper <andrew.cooper3%citrix.com@localhost>
+Reviewed-by: Jan Beulich <jbeulich%suse.com@localhost>
+(cherry picked from commit 8d03080d2a339840d3a59e0932a94f804e45110d)
+
+diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc
+index 443802b3d2e5..2392537954c8 100644
+--- docs/misc/xen-command-line.pandoc.orig
++++ docs/misc/xen-command-line.pandoc
+@@ -2205,9 +2205,9 @@ to use.
+
+ If Xen was compiled with INDIRECT_THUNK support, `bti-thunk=` can be used to
+ select which of the thunks gets patched into the `__x86_indirect_thunk_%reg`
+-locations. The default thunk is `retpoline` (generally preferred for Intel
+-hardware), with the alternatives being `jmp` (a `jmp *%reg` gadget, minimal
+-overhead), and `lfence` (an `lfence; jmp *%reg` gadget, preferred for AMD).
++locations. The default thunk is `retpoline` (generally preferred), with the
++alternatives being `jmp` (a `jmp *%reg` gadget, minimal overhead), and
++`lfence` (an `lfence; jmp *%reg` gadget).
+
+ On hardware supporting IBRS (Indirect Branch Restricted Speculation), the
+ `ibrs=` option can be used to force or prevent Xen using the feature itself.
+diff --git a/xen/arch/x86/spec_ctrl.c b/xen/arch/x86/spec_ctrl.c
+index 9301d95bd705..7ded6ecba197 100644
+--- xen/arch/x86/spec_ctrl.c.orig
++++ xen/arch/x86/spec_ctrl.c
+@@ -367,14 +367,19 @@ static void __init print_details(enum ind_thunk thunk, uint64_t caps)
+ "\n");
+
+ /* Settings for Xen's protection, irrespective of guests. */
+- printk(" Xen settings: BTI-Thunk %s, SPEC_CTRL: %s%s%s, Other:%s%s%s%s%s\n",
++ printk(" Xen settings: BTI-Thunk %s, SPEC_CTRL: %s%s%s%s, Other:%s%s%s%s%s\n",
+ thunk == THUNK_NONE ? "N/A" :
+ thunk == THUNK_RETPOLINE ? "RETPOLINE" :
+ thunk == THUNK_LFENCE ? "LFENCE" :
+ thunk == THUNK_JMP ? "JMP" : "?",
+- !boot_cpu_has(X86_FEATURE_IBRSB) ? "No" :
++ (!boot_cpu_has(X86_FEATURE_IBRSB) &&
++ !boot_cpu_has(X86_FEATURE_IBRS)) ? "No" :
+ (default_xen_spec_ctrl & SPEC_CTRL_IBRS) ? "IBRS+" : "IBRS-",
+- !boot_cpu_has(X86_FEATURE_SSBD) ? "" :
++ (!boot_cpu_has(X86_FEATURE_STIBP) &&
++ !boot_cpu_has(X86_FEATURE_AMD_STIBP)) ? "" :
++ (default_xen_spec_ctrl & SPEC_CTRL_STIBP) ? " STIBP+" : " STIBP-",
++ (!boot_cpu_has(X86_FEATURE_SSBD) &&
++ !boot_cpu_has(X86_FEATURE_AMD_SSBD)) ? "" :
+ (default_xen_spec_ctrl & SPEC_CTRL_SSBD) ? " SSBD+" : " SSBD-",
+ !(caps & ARCH_CAPS_TSX_CTRL) ? "" :
+ (opt_tsx & 1) ? " TSX+" : " TSX-",
+@@ -916,10 +921,23 @@ void __init init_speculation_mitigations(void)
+ /*
+ * First, disable the use of retpolines if Xen is using shadow stacks, as
+ * they are incompatible.
++ *
++ * In the absence of retpolines, IBRS needs to be used for speculative
++ * safety. All CET-capable hardware has efficient IBRS.
+ */
+- if ( cpu_has_xen_shstk &&
+- (opt_thunk == THUNK_DEFAULT || opt_thunk == THUNK_RETPOLINE) )
+- thunk = THUNK_JMP;
++ if ( cpu_has_xen_shstk )
++ {
++ if ( !boot_cpu_has(X86_FEATURE_IBRSB) )
++ printk(XENLOG_WARNING "?!? CET active, but no MSR_SPEC_CTRL?\n");
++ else if ( opt_ibrs == -1 )
++ {
++ opt_ibrs = ibrs = true;
++ default_xen_spec_ctrl |= SPEC_CTRL_IBRS | SPEC_CTRL_STIBP;
++ }
++
++ if ( opt_thunk == THUNK_DEFAULT || opt_thunk == THUNK_RETPOLINE )
++ thunk = THUNK_JMP;
++ }
+
+ /*
+ * Has the user specified any custom BTI mitigations? If so, follow their
+@@ -951,16 +951,10 @@
+ if ( IS_ENABLED(CONFIG_INDIRECT_THUNK) )
+ {
+ /*
+- * AMD's recommended mitigation is to set lfence as being dispatch
+- * serialising, and to use IND_THUNK_LFENCE.
+- */
+- if ( cpu_has_lfence_dispatch )
+- thunk = THUNK_LFENCE;
+- /*
+- * On Intel hardware, we'd like to use retpoline in preference to
++ * On all hardware, we'd like to use retpoline in preference to
+ * IBRS, but only if it is safe on this hardware.
+ */
+- else if ( retpoline_safe(caps) )
++ if ( retpoline_safe(caps) )
+ thunk = THUNK_RETPOLINE;
+ else if ( boot_cpu_has(X86_FEATURE_IBRSB) )
+ ibrs = true;
diff -r 88b5499bc7bd -r b09d9be17fa4 sysutils/xenkernel415/patches/patch-XSA399
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/sysutils/xenkernel415/patches/patch-XSA399 Fri Jun 24 13:07:52 2022 +0000
@@ -0,0 +1,47 @@
+$NetBSD: patch-XSA399,v 1.1 2022/06/24 13:07:52 bouyer Exp $
+
+From: Jan Beulich <jbeulich%suse.com@localhost>
+Subject: VT-d: correct ordering of operations in cleanup_domid_map()
+
+The function may be called without any locks held (leaving aside the
+domctl one, which we surely don't want to depend on here), so needs to
+play safe wrt other accesses to domid_map[] and domid_bitmap[]. This is
+to avoid context_set_domain_id()'s writing of domid_map[] to be reset to
+zero right away in the case of it racing the freeing of a DID.
+
+For the interaction with context_set_domain_id() and ->domid_map[] reads
+see the code comment.
+
+{check_,}cleanup_domid_map() are called with pcidevs_lock held or during
+domain cleanup only (and pcidevs_lock is also held around
+context_set_domain_id()), i.e. racing calls with the same (dom, iommu)
+tuple cannot occur.
+
+domain_iommu_domid(), besides its use by cleanup_domid_map(), has its
+result used only to control flushing, and hence a stale result would
+only lead to a stray extra flush.
+
+This is CVE-2022-26357 / XSA-399.
+
+Fixes: b9c20c78789f ("VT-d: per-iommu domain-id")
+Signed-off-by: Jan Beulich <jbeulich%suse.com@localhost>
+Reviewed-by: Roger Pau Monné <roger.pau%citrix.com@localhost>
+
+--- xen/drivers/passthrough/vtd/iommu.c.orig
++++ xen/drivers/passthrough/vtd/iommu.c
+@@ -152,8 +152,14 @@ static void cleanup_domid_map(struct dom
Home |
Main Index |
Thread Index |
Old Index