Source-Changes-HG archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
[pkgsrc/trunk]: pkgsrc/sysutils/xenkernel411 Update to 4.11.4nb1
details: https://anonhg.NetBSD.org/pkgsrc/rev/c65156c35b52
branches: trunk
changeset: 437480:c65156c35b52
user: bouyer <bouyer%pkgsrc.org@localhost>
date: Mon Aug 24 10:35:35 2020 +0000
description:
Update to 4.11.4nb1
Keep PKGREVISION at 1 to reflect that it's not a stock Xen 4.11.4 kernel,
we have additinnal security fixes (all relevant patches from upstream to
date).
Changes: mosly bug fixes and improvements; better support for newer AMD CPUs.
full changelog at https://xenproject.org/downloads/xen-project-archives/xen-proj
ect-4-11-series/xen-project-4-11-4/
diffstat:
sysutils/xenkernel411/Makefile | 7 +-
sysutils/xenkernel411/distinfo | 20 +-
sysutils/xenkernel411/patches/patch-XSA307 | 101 --------
sysutils/xenkernel411/patches/patch-XSA308 | 76 ------
sysutils/xenkernel411/patches/patch-XSA309 | 60 -----
sysutils/xenkernel411/patches/patch-XSA310 | 348 -----------------------------
sysutils/xenkernel411/patches/patch-XSA311 | 189 ---------------
sysutils/xenkernel411/patches/patch-XSA313 | 160 -------------
sysutils/xenkernel411/patches/patch-XSA316 | 32 --
sysutils/xenkernel411/patches/patch-XSA318 | 41 ---
sysutils/xenkernel411/patches/patch-XSA321 | 11 +-
11 files changed, 20 insertions(+), 1025 deletions(-)
diffs (truncated from 1111 to 300 lines):
diff -r ae2c44f28f1f -r c65156c35b52 sysutils/xenkernel411/Makefile
--- a/sysutils/xenkernel411/Makefile Mon Aug 24 10:33:27 2020 +0000
+++ b/sysutils/xenkernel411/Makefile Mon Aug 24 10:35:35 2020 +0000
@@ -1,7 +1,8 @@
-# $NetBSD: Makefile,v 1.14 2020/07/16 09:57:17 bouyer Exp $
+# $NetBSD: Makefile,v 1.15 2020/08/24 10:35:35 bouyer Exp $
-VERSION= 4.11.3
-PKGREVISION= 3
+VERSION= 4.11.4
+#keep >= 1 if we have security patches
+PKGREVISION= 1
DISTNAME= xen-${VERSION}
PKGNAME= xenkernel411-${VERSION}
CATEGORIES= sysutils
diff -r ae2c44f28f1f -r c65156c35b52 sysutils/xenkernel411/distinfo
--- a/sysutils/xenkernel411/distinfo Mon Aug 24 10:33:27 2020 +0000
+++ b/sysutils/xenkernel411/distinfo Mon Aug 24 10:35:35 2020 +0000
@@ -1,22 +1,14 @@
-$NetBSD: distinfo,v 1.12 2020/07/16 09:57:17 bouyer Exp $
+$NetBSD: distinfo,v 1.13 2020/08/24 10:35:35 bouyer Exp $
-SHA1 (xen411/xen-4.11.3.tar.gz) = 2d77152168d6f9dcea50db9cb8e3e6a0720a4a1b
-RMD160 (xen411/xen-4.11.3.tar.gz) = cfb2e699842867b60d25a01963c564a6c5e580da
-SHA512 (xen411/xen-4.11.3.tar.gz) = 2204e490e9fc357a05983a9bf4e7345e1d364fe00400ce473988dcb9ca7d4e2b921fe10f095cbbc64248130a92d22c6f0d154dcae250a57a7f915df32e3dc436
-Size (xen411/xen-4.11.3.tar.gz) = 25180826 bytes
+SHA1 (xen411/xen-4.11.4.tar.gz) = 6c8cdf441621c14dc5345196b48df6982c060c4f
+RMD160 (xen411/xen-4.11.4.tar.gz) = 49819fcd1de3985d4dea370be962548c862f2933
+SHA512 (xen411/xen-4.11.4.tar.gz) = 8383f0b369fa08c8ecfdd68f902a2aaad140146a183131c50c020fe04c2f1e829c219b9bd9923fa8f1c180e1e7c6e73d0d68b7015fc39fd3b7f59e55c680cedb
+Size (xen411/xen-4.11.4.tar.gz) = 25184564 bytes
SHA1 (patch-Config.mk) = 9372a09efd05c9fbdbc06f8121e411fcb7c7ba65
-SHA1 (patch-XSA307) = afd88b8294b0dbbc32e1d1aa74eb887d2da6695a
-SHA1 (patch-XSA308) = bda9ef732e0b6578ce8f7f0f7aa0a4189da41e86
-SHA1 (patch-XSA309) = 78cf7306e9d1efcbf2ebf425025d46948ae83019
-SHA1 (patch-XSA310) = 77b711f4b75de1d473a6988eb6f2b48e37cc353a
-SHA1 (patch-XSA311) = 4d3e6cc39c2b95cb3339961271df2bc885667927
-SHA1 (patch-XSA313) = b2f281d6aed1207727cd454dcb5e914c7f6fb44b
-SHA1 (patch-XSA316) = 9cce683315e4c1ca6d53b578e69ae71e1db2b3eb
SHA1 (patch-XSA317) = 3a3e7bf8f115bebaf56001afcf68c2bd501c00a5
-SHA1 (patch-XSA318) = d0dcbb99ab584098aed7995a7a05d5bf4ac28d47
SHA1 (patch-XSA319) = 4954bdc849666e1c735c3281256e4850c0594ee8
SHA1 (patch-XSA320) = 38d84a2ded4ccacee455ba64eb3b369e5661fbfd
-SHA1 (patch-XSA321) = 5281304282a26ee252344ec26b07d25ac4ce8b54
+SHA1 (patch-XSA321) = 1f15b2e3c0f7f2d7335879d3a83c1557ac9de806
SHA1 (patch-XSA328) = a9b02c183a5dbfb6c0fe50824f18896fcab4a9e9
SHA1 (patch-xen_Makefile) = 465388d80de414ca3bb84faefa0f52d817e423a6
SHA1 (patch-xen_Rules.mk) = c743dc63f51fc280d529a7d9e08650292c171dac
diff -r ae2c44f28f1f -r c65156c35b52 sysutils/xenkernel411/patches/patch-XSA307
--- a/sysutils/xenkernel411/patches/patch-XSA307 Mon Aug 24 10:33:27 2020 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,101 +0,0 @@
-$NetBSD: patch-XSA307,v 1.1 2019/12/13 13:44:21 bouyer Exp $
-
-From: Jan Beulich <jbeulich%suse.com@localhost>
-Subject: x86+Arm32: make find_next_{,zero_}bit() have well defined behavior
-
-These functions getting used with the 2nd and 3rd arguments being equal
-wasn't well defined: Arm64 reliably returns the value of the 2nd
-argument in this case, while on x86 for bitmaps up to 64 bits wide the
-return value was undefined (due to the undefined behavior of a shift of
-a value by the number of bits it's wide) when the incoming value was 64.
-On Arm32 an actual out of bounds access would happen when the
-size/offset value is a multiple of 32; if this access doesn't fault, the
-return value would have been sufficiently correct afaict.
-
-Make the functions consistently tolerate the last two arguments being
-equal (and in fact the 3rd argument being greater or equal to the 2nd),
-in favor of finding and fixing all the use sites that violate the
-original more strict assumption.
-
-This is XSA-307.
-
-Signed-off-by: Jan Beulich <jbeulich%suse.com@localhost>
-Acked-by: Julien Grall <julien%xen.org@localhost>
----
-The most obvious (albeit still indirect) exposure to guests is
-evtchn_check_pollers(), which imo makes this a security issue at least
-for Arm32.
-
-This was originally already discussed between (at least) Andrew and me,
-and I don't really recall who brought up the issue first.
-
-Note that Arm's Linux origin of the code may call for syncing
-publication with them. Then again I don't want to tell them just to see
-them go public ahead of us.
-
---- xen/arch/arm/arm32/lib/findbit.S.orig
-+++ xen/arch/arm/arm32/lib/findbit.S
-@@ -42,8 +42,8 @@ ENDPROC(_find_first_zero_bit_le)
- * Prototype: int find_next_zero_bit(void *addr, unsigned int maxbit, int offset)
- */
- ENTRY(_find_next_zero_bit_le)
-- teq r1, #0
-- beq 3b
-+ cmp r1, r2
-+ bls 3b
- ands ip, r2, #7
- beq 1b @ If new byte, goto old routine
- ARM( ldrb r3, [r0, r2, lsr #3] )
-@@ -83,8 +83,8 @@ ENDPROC(_find_first_bit_le)
- * Prototype: int find_next_zero_bit(void *addr, unsigned int maxbit, int offset)
- */
- ENTRY(_find_next_bit_le)
-- teq r1, #0
-- beq 3b
-+ cmp r1, r2
-+ bls 3b
- ands ip, r2, #7
- beq 1b @ If new byte, goto old routine
- ARM( ldrb r3, [r0, r2, lsr #3] )
-@@ -117,8 +117,8 @@ ENTRY(_find_first_zero_bit_be)
- ENDPROC(_find_first_zero_bit_be)
-
- ENTRY(_find_next_zero_bit_be)
-- teq r1, #0
-- beq 3b
-+ cmp r1, r2
-+ bls 3b
- ands ip, r2, #7
- beq 1b @ If new byte, goto old routine
- eor r3, r2, #0x18 @ big endian byte ordering
-@@ -151,8 +151,8 @@ ENTRY(_find_first_bit_be)
- ENDPROC(_find_first_bit_be)
-
- ENTRY(_find_next_bit_be)
-- teq r1, #0
-- beq 3b
-+ cmp r1, r2
-+ bls 3b
- ands ip, r2, #7
- beq 1b @ If new byte, goto old routine
- eor r3, r2, #0x18 @ big endian byte ordering
---- xen/include/asm-x86/bitops.h.orig
-+++ xen/include/asm-x86/bitops.h
-@@ -358,7 +358,7 @@ static always_inline unsigned int __scan
- const unsigned long *a__ = (addr); \
- unsigned int s__ = (size); \
- unsigned int o__ = (off); \
-- if ( __builtin_constant_p(size) && !s__ ) \
-+ if ( o__ >= s__ ) \
- r__ = s__; \
- else if ( __builtin_constant_p(size) && s__ <= BITS_PER_LONG ) \
- r__ = o__ + __scanbit(*(const unsigned long *)(a__) >> o__, s__); \
-@@ -390,7 +390,7 @@ static always_inline unsigned int __scan
- const unsigned long *a__ = (addr); \
- unsigned int s__ = (size); \
- unsigned int o__ = (off); \
-- if ( __builtin_constant_p(size) && !s__ ) \
-+ if ( o__ >= s__ ) \
- r__ = s__; \
- else if ( __builtin_constant_p(size) && s__ <= BITS_PER_LONG ) \
- r__ = o__ + __scanbit(~*(const unsigned long *)(a__) >> o__, s__); \
diff -r ae2c44f28f1f -r c65156c35b52 sysutils/xenkernel411/patches/patch-XSA308
--- a/sysutils/xenkernel411/patches/patch-XSA308 Mon Aug 24 10:33:27 2020 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,76 +0,0 @@
-$NetBSD: patch-XSA308,v 1.1 2019/12/13 13:44:21 bouyer Exp $
-
-From: Andrew Cooper <andrew.cooper3%citrix.com@localhost>
-Subject: x86/vtx: Work around SingleStep + STI/MovSS VMEntry failures
-
-See patch comment for technical details.
-
-Concerning the timeline, this was first discovered in the aftermath of
-XSA-156 which caused #DB to be intercepted unconditionally, but only in
-its SingleStep + STI form which is restricted to privileged software.
-
-After working with Intel and identifying the problematic vmentry check,
-this workaround was suggested, and the patch was posted in an RFC
-series. Outstanding work for that series (not breaking Introspection)
-is still pending, and this fix from it (which wouldn't have been good
-enough in its original form) wasn't committed.
-
-A vmentry failure was reported to xen-devel, and debugging identified
-this bug in its SingleStep + MovSS form by way of INT1, which does not
-involve the use of any privileged instructions, and proving this to be a
-security issue.
-
-This is XSA-308
-
-Reported-by: Håkon Alstadheim <hakon%alstadheim.priv.no@localhost>
-Signed-off-by: Andrew Cooper <andrew.cooper3%citrix.com@localhost>
-Reviewed-by: Jan Beulich <jbeulich%suse.com@localhost>
-Acked-by: Kevin Tian <kevin.tian%intel.com@localhost>
-
-diff --git a/xen/arch/x86/hvm/vmx/vmx.c b/xen/arch/x86/hvm/vmx/vmx.c
-index 6a5eeb5c13..59b836f43f 100644
---- xen/arch/x86/hvm/vmx/vmx.c.orig
-+++ xen/arch/x86/hvm/vmx/vmx.c
-@@ -3816,6 +3816,42 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
- HVMTRACE_1D(TRAP_DEBUG, exit_qualification);
- __restore_debug_registers(v);
- write_debugreg(6, exit_qualification | DR_STATUS_RESERVED_ONE);
-+
-+ /*
-+ * Work around SingleStep + STI/MovSS VMEntry failures.
-+ *
-+ * We intercept #DB unconditionally to work around CVE-2015-8104 /
-+ * XSA-156 (guest-kernel induced host DoS).
-+ *
-+ * STI/MovSS shadows block/defer interrupts/exceptions (exact
-+ * details are complicated and poorly documented). Debug
-+ * exceptions delayed for any reason are stored in the
-+ * PENDING_DBG_EXCEPTIONS field.
-+ *
-+ * The falling edge of PENDING_DBG causes #DB to be delivered,
-+ * resulting in a VMExit, as #DB is intercepted. The VMCS still
-+ * reports blocked-by-STI/MovSS.
-+ *
-+ * The VMEntry checks when EFLAGS.TF is set don't like a VMCS in
-+ * this state. Despite a #DB queued in VMENTRY_INTR_INFO, the
-+ * state is rejected as DR6.BS isn't pending. Fix this up.
-+ */
-+ if ( unlikely(regs->eflags & X86_EFLAGS_TF) )
-+ {
-+ unsigned long int_info;
-+
-+ __vmread(GUEST_INTERRUPTIBILITY_INFO, &int_info);
-+
-+ if ( int_info & (VMX_INTR_SHADOW_STI | VMX_INTR_SHADOW_MOV_SS) )
-+ {
-+ unsigned long pending_dbg;
-+
-+ __vmread(GUEST_PENDING_DBG_EXCEPTIONS, &pending_dbg);
-+ __vmwrite(GUEST_PENDING_DBG_EXCEPTIONS,
-+ pending_dbg | DR_STEP);
-+ }
-+ }
-+
- if ( !v->domain->debugger_attached )
- {
- unsigned long insn_len = 0;
diff -r ae2c44f28f1f -r c65156c35b52 sysutils/xenkernel411/patches/patch-XSA309
--- a/sysutils/xenkernel411/patches/patch-XSA309 Mon Aug 24 10:33:27 2020 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,60 +0,0 @@
-$NetBSD: patch-XSA309,v 1.1 2019/12/13 13:44:21 bouyer Exp $
-
-From 523e3974ed2213719a19218f5b246e382ceef18a Mon Sep 17 00:00:00 2001
-From: George Dunlap <george.dunlap%citrix.com@localhost>
-Date: Wed, 30 Oct 2019 17:05:28 +0000
-Subject: [PATCH] x86/mm: Don't reset linear_pt_count on partial validation
-
-"Linear pagetables" is a technique which involves either pointing a
-pagetable at itself, or to another pagetable the same or higher level.
-Xen has limited support for linear pagetables: A page may either point
-to itself, or point to another page of the same level (i.e., L2 to L2,
-L3 to L3, and so on).
-
-XSA-240 introduced an additional restriction that limited the "depth"
-of such chains by allowing pages to either *point to* other pages of
-the same level, or *be pointed to* by other pages of the same level,
-but not both. To implement this, we keep track of the number of
-outstanding times a page points to or is pointed to another page
-table, to prevent both from happening at the same time.
-
-Unfortunately, the original commit introducing this reset this count
-when resuming validation of a partially-validated pagetable, dropping
-some "linear_pt_entry" counts.
-
-On debug builds on systems where guests used this feature, this might
-lead to crashes that look like this:
-
- Assertion 'oc > 0' failed at mm.c:874
-
-Worse, if an attacker could engineer such a situation to occur, they
-might be able to make loops or other abitrary chains of linear
-pagetables, leading to the denial-of-service situation outlined in
-XSA-240.
-
-This is XSA-309.
-
-Reported-by: Manuel Bouyer <bouyer%antioche.eu.org@localhost>
-Signed-off-by: George Dunlap <george.dunlap%citrix.com@localhost>
-Reviewed-by: Jan Beulich <jbeulich%suse.com@localhost>
----
- xen/arch/x86/mm.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
-index 7d4dd80a85..01393fb0da 100644
---- xen/arch/x86/mm.c.orig
-+++ xen/arch/x86/mm.c
-@@ -3059,8 +3059,8 @@ static int _get_page_type(struct page_info *page, unsigned long type,
- {
- page->nr_validated_ptes = 0;
- page->partial_flags = 0;
-+ page->linear_pt_count = 0;
- }
-- page->linear_pt_count = 0;
- rc = alloc_page_type(page, type, preemptible);
- }
-
---
-2.24.0
-
diff -r ae2c44f28f1f -r c65156c35b52 sysutils/xenkernel411/patches/patch-XSA310
--- a/sysutils/xenkernel411/patches/patch-XSA310 Mon Aug 24 10:33:27 2020 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,348 +0,0 @@
Home |
Main Index |
Thread Index |
Old Index