pkgsrc-Changes-HG archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
[pkgsrc/trunk]: pkgsrc/sysutils/xenkernel415 Update xenkernel415 to 4.15.3.
details: https://anonhg.NetBSD.org/pkgsrc/rev/05b94154f376
branches: trunk
changeset: 381372:05b94154f376
user: bouyer <bouyer%pkgsrc.org@localhost>
date: Tue Jul 05 15:53:45 2022 +0000
description:
Update xenkernel415 to 4.15.3.
Changes are mostly bugfixes, including all security fixes up to XSA404
(which we already had in 4.15.2nb2)
diffstat:
sysutils/xenkernel415/Makefile | 5 +-
sysutils/xenkernel415/distinfo | 15 +-
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, 6 insertions(+), 5058 deletions(-)
diffs (truncated from 5111 to 300 lines):
diff -r 64d3ea751890 -r 05b94154f376 sysutils/xenkernel415/Makefile
--- a/sysutils/xenkernel415/Makefile Tue Jul 05 12:58:28 2022 +0000
+++ b/sysutils/xenkernel415/Makefile Tue Jul 05 15:53:45 2022 +0000
@@ -1,9 +1,8 @@
-# $NetBSD: Makefile,v 1.6 2022/06/24 13:07:52 bouyer Exp $
+# $NetBSD: Makefile,v 1.7 2022/07/05 15:53:45 bouyer Exp $
-VERSION= 4.15.2
+VERSION= 4.15.3
DISTNAME= xen-${VERSION}
PKGNAME= xenkernel415-${VERSION}
-PKGREVISION= 2
CATEGORIES= sysutils
MASTER_SITES= https://downloads.xenproject.org/release/xen/${VERSION}/
DIST_SUBDIR= xen415
diff -r 64d3ea751890 -r 05b94154f376 sysutils/xenkernel415/distinfo
--- a/sysutils/xenkernel415/distinfo Tue Jul 05 12:58:28 2022 +0000
+++ b/sysutils/xenkernel415/distinfo Tue Jul 05 15:53:45 2022 +0000
@@ -1,16 +1,9 @@
-$NetBSD: distinfo,v 1.6 2022/06/24 13:07:52 bouyer Exp $
+$NetBSD: distinfo,v 1.7 2022/07/05 15:53:45 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
+BLAKE2s (xen415/xen-4.15.3.tar.gz) = ce8af440eed3c04c6a14454ad7138d78ee179e5fc875c1eb06e6b7ea1454dda8
+SHA512 (xen415/xen-4.15.3.tar.gz) = c25903cc263891885ec76500488405226c8e025bb461d2bf0d590b9bd2d7ca5c2693de7ecc38b3655bfd6793cc96314826559f14a09cc139de8cfdbeb914cbd3
+Size (xen415/xen-4.15.3.tar.gz) = 40793144 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 64d3ea751890 -r 05b94154f376 sysutils/xenkernel415/patches/patch-XSA397
--- a/sysutils/xenkernel415/patches/patch-XSA397 Tue Jul 05 12:58:28 2022 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,100 +0,0 @@
-$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 64d3ea751890 -r 05b94154f376 sysutils/xenkernel415/patches/patch-XSA398
--- a/sysutils/xenkernel415/patches/patch-XSA398 Tue Jul 05 12:58:28 2022 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,120 +0,0 @@
-$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 64d3ea751890 -r 05b94154f376 sysutils/xenkernel415/patches/patch-XSA399
--- a/sysutils/xenkernel415/patches/patch-XSA399 Tue Jul 05 12:58:28 2022 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,47 +0,0 @@
-$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>
-
Home |
Main Index |
Thread Index |
Old Index