=> Bootstrap dependency digest>=20010302: found digest-20190127 ===> Skipping vulnerability checks. WARNING: No /var/db/pkg/pkg-vulnerabilities file found. WARNING: To fix run: `/usr/sbin/pkg_admin -K /var/db/pkg fetch-pkg-vulnerabilities'. => Checksum SHA1 OK for xen-4.6.6.tar.gz => Checksum RMD160 OK for xen-4.6.6.tar.gz => Checksum SHA512 OK for xen-4.6.6.tar.gz ===> Installing dependencies for xenkernel46-4.6.6nb3 ========================================================================== The following variables will affect the build process of this package, xenkernel46-4.6.6nb3. Their current value is shown below: * PYTHON_VERSION_DEFAULT = 37 Based on these variables, the following variables have been set: * PYPACKAGE = python27 You may want to abort the process now with CTRL-C and change their value before continuing. Be sure to run `/usr/bin/make clean' after the changes. ========================================================================== => Tool dependency gmake>=3.81: found gmake-4.2.1nb1 => Tool dependency checkperms>=1.1: found checkperms-1.12 => Build dependency python27>=2.7.1nb2: found python27-2.7.18 => Build dependency cwrappers>=20150314: found cwrappers-20180325 ===> Skipping vulnerability checks. WARNING: No /var/db/pkg/pkg-vulnerabilities file found. WARNING: To fix run: `/usr/sbin/pkg_admin -K /var/db/pkg fetch-pkg-vulnerabilities'. ===> Overriding tools for xenkernel46-4.6.6nb3 ===> Extracting for xenkernel46-4.6.6nb3 ===> Patching for xenkernel46-4.6.6nb3 => Applying pkgsrc patches for xenkernel46-4.6.6nb3 => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-Config.mk => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-Config.mk Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-Config.mk,v 1.1.1.1 2016/07/04 07:25:13 jnemeth Exp $ | |--- Config.mk.orig 2015-01-12 17:53:24.000000000 +0100 |+++ Config.mk 2015-01-19 12:29:14.000000000 +0100 -------------------------- Patching file Config.mk using Plan A... Hunk #1 succeeded at 39. done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA226 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA226 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA226,v 1.1 2017/10/17 10:57:34 bouyer Exp $ | |From: Jan Beulich |Subject: gnttab: don't use possibly unbounded tail calls | |There is no guarantee that the compiler would actually translate them |to branches instead of calls, so only ones with a known recursion limit |are okay: |- __release_grant_for_copy() can call itself only once, as | __acquire_grant_for_copy() won't permit use of multi-level transitive | grants, |- __acquire_grant_for_copy() is fine to call itself with the last | argument false, as that prevents further recursion, |- __acquire_grant_for_copy() must not call itself to recover from an | observed change to the active entry's pin count | |This is part of CVE-2017-12135 / XSA-226. | |Signed-off-by: Jan Beulich | |--- xen/common/compat/grant_table.c.orig |+++ xen/common/compat/grant_table.c -------------------------- Patching file xen/common/compat/grant_table.c using Plan A... Hunk #1 succeeded at 258. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/common/grant_table.c.orig |+++ xen/common/grant_table.c -------------------------- Patching file xen/common/grant_table.c using Plan A... Hunk #1 succeeded at 2072 (offset -17 lines). Hunk #2 succeeded at 2226 (offset -17 lines). Hunk #3 succeeded at 2238 (offset -17 lines). Hunk #4 succeeded at 2545 (offset -17 lines). Hunk #5 succeeded at 2555 (offset -17 lines). Hunk #6 succeeded at 2564 (offset -17 lines). Hunk #7 succeeded at 2585 (offset -17 lines). Hunk #8 succeeded at 2595 (offset -17 lines). Hunk #9 succeeded at 3146 (offset -17 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |From: Jan Beulich |Subject: gnttab: fix transitive grant handling | |Processing of transitive grants must not use the fast path, or else |reference counting breaks due to the skipped recursive call to |__acquire_grant_for_copy() (its __release_grant_for_copy() |counterpart occurs independent of original pin count). Furthermore |after re-acquiring temporarily dropped locks we need to verify no grant |properties changed if the original pin count was non-zero; checking |just the pin counts is sufficient only for well-behaved guests. As a |result, __release_grant_for_copy() needs to mirror that new behavior. | |Furthermore a __release_grant_for_copy() invocation was missing on the |retry path of __acquire_grant_for_copy(), and gnttab_set_version() also |needs to bail out upon encountering a transitive grant. | |This is part of CVE-2017-12135 / XSA-226. | |Reported-by: Andrew Cooper |Signed-off-by: Jan Beulich |Reviewed-by: Andrew Cooper | |--- xen/common/grant_table.c.orig |+++ xen/common/grant_table.c -------------------------- Patching file xen/common/grant_table.c using Plan A... Hunk #1 succeeded at 2019 (offset -17 lines). Hunk #2 succeeded at 2050 (offset -17 lines). Hunk #3 succeeded at 2062 (offset -17 lines). Hunk #4 succeeded at 2139 (offset -17 lines). Hunk #5 succeeded at 2261 (offset -17 lines). Hunk #6 succeeded at 2692 (offset -17 lines). done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA227 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA227 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA227,v 1.1 2017/10/17 10:57:34 bouyer Exp $ | |From 697edc414352e89f29ca3de744a76c1625c0466c Mon Sep 17 00:00:00 2001 |From: Andrew Cooper |Date: Tue, 20 Jun 2017 19:18:54 +0100 |Subject: [PATCH] x86/grant: Disallow misaligned PTEs | |Pagetable entries must be aligned to function correctly. Disallow attempts |from the guest to have a grant PTE created at a misaligned address, which |would result in corruption of the L1 table with largely-guest-controlled |values. | |This is XSA-227 | |Signed-off-by: Andrew Cooper |Reviewed-by: Jan Beulich |--- | xen/arch/x86/mm.c | 13 +++++++++++++ | xen/include/xen/config.h | 2 ++ | 2 files changed, 15 insertions(+) | |diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c |index 213b52a..3bf728b 100644 |--- xen/arch/x86/mm.c.orig |+++ xen/arch/x86/mm.c -------------------------- Patching file xen/arch/x86/mm.c using Plan A... Hunk #1 succeeded at 3878. Hunk #2 succeeded at 3938. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/xen/include/xen/config.h b/xen/include/xen/config.h |index f7258c7..ded8156 100644 |--- xen/include/xen/config.h.orig |+++ xen/include/xen/config.h -------------------------- Patching file xen/include/xen/config.h using Plan A... Hunk #1 succeeded at 72. Hmm... Ignoring the trailing garbage. done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA228 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA228 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA228,v 1.1 2017/10/17 10:57:34 bouyer Exp $ | |From cb91f4c43bd4158daa6561c73921a6455176f278 Mon Sep 17 00:00:00 2001 |From: Jan Beulich |Date: Mon, 31 Jul 2017 15:17:56 +0100 |Subject: [PATCH] gnttab: split maptrack lock to make it fulfill its purpose | again | |The way the lock is currently being used in get_maptrack_handle(), it |protects only the maptrack limit: The function acts on current's list |only, so races on list accesses are impossible even without the lock. | |Otoh list access races are possible between __get_maptrack_handle() and |put_maptrack_handle(), due to the invocation of the former for other |than current from steal_maptrack_handle(). Introduce a per-vCPU lock |for list accesses to become race free again. This lock will be |uncontended except when it becomes necessary to take the steal path, |i.e. in the common case there should be no meaningful performance |impact. | |When in get_maptrack_handle adds a stolen entry to a fresh, empty, |freelist, we think that there is probably no concurrency. However, |this is not a fast path and adding the locking there makes the code |clearly correct. | |Also, while we are here: the stolen maptrack_entry's tail pointer was |not properly set. Set it. | |This is XSA-228. | |Reported-by: Ian Jackson |Signed-off-by: Jan Beulich |Signed-off-by: Ian Jackson |--- | docs/misc/grant-tables.txt | 7 ++++++- | xen/common/grant_table.c | 30 ++++++++++++++++++++++++------ | xen/include/xen/grant_table.h | 2 +- | xen/include/xen/sched.h | 1 + | 4 files changed, 32 insertions(+), 8 deletions(-) | |diff --git a/docs/misc/grant-tables.txt b/docs/misc/grant-tables.txt |index 417ce2d..64da5cf 100644 |--- docs/misc/grant-tables.txt.orig |+++ docs/misc/grant-tables.txt -------------------------- Patching file docs/misc/grant-tables.txt using Plan A... Hunk #1 succeeded at 87. Hunk #2 succeeded at 103. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c |index f9654f1..593121c 100644 |--- xen/common/grant_table.c.orig |+++ xen/common/grant_table.c -------------------------- Patching file xen/common/grant_table.c using Plan A... Hunk #1 succeeded at 296 (offset -8 lines). Hunk #2 succeeded at 313 (offset -8 lines). Hunk #3 succeeded at 382 (offset -8 lines). Hunk #4 succeeded at 392 (offset -8 lines). Hunk #5 succeeded at 417 (offset -8 lines). Hunk #6 succeeded at 428 (offset -8 lines). Hunk #7 succeeded at 466 (offset -8 lines). Hunk #8 succeeded at 3484 (offset -7 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/xen/include/xen/grant_table.h b/xen/include/xen/grant_table.h |index 4e77899..100f2b3 100644 |--- xen/include/xen/grant_table.h.orig |+++ xen/include/xen/grant_table.h -------------------------- Patching file xen/include/xen/grant_table.h using Plan A... Hunk #1 succeeded at 75 (offset -3 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h |index 1fbda87..ff0f38f 100644 |--- xen/include/xen/sched.h.orig |+++ xen/include/xen/sched.h -------------------------- Patching file xen/include/xen/sched.h using Plan A... Hunk #1 succeeded at 222 (offset -1 lines). Hmm... Ignoring the trailing garbage. done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA230 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA230 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA230,v 1.1 2017/10/17 10:57:34 bouyer Exp $ | |From: Jan Beulich |Subject: gnttab: correct pin status fixup for copy | |Regardless of copy operations only setting GNTPIN_hst*, GNTPIN_dev* |also need to be taken into account when deciding whether to clear |_GTF_{read,writ}ing. At least for consistency with code elsewhere the |read part better doesn't use any mask at all. | |This is XSA-230. | |Signed-off-by: Jan Beulich |Reviewed-by: Andrew Cooper |diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c |index ae34547..9c9d33c 100644 |--- xen/common/grant_table.c.orig |+++ xen/common/grant_table.c -------------------------- Patching file xen/common/grant_table.c using Plan A... Hunk #1 succeeded at 2096 (offset -11 lines). Hunk #2 succeeded at 2345 (offset 27 lines). done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA231 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA231 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA231,v 1.1 2017/10/17 10:57:34 bouyer Exp $ | |From: George Dunlap |Subject: xen/mm: make sure node is less than MAX_NUMNODES | |The output of MEMF_get_node(memflags) can be as large as nodeid_t can |hold (currently 255). This is then used as an index to arrays of size |MAX_NUMNODE, which is 64 on x86 and 1 on ARM, can be passed in by an |untrusted guest (via memory_exchange and increase_reservation) and is |not currently bounds-checked. | |Check the value in page_alloc.c before using it, and also check the |value in the hypercall call sites and return -EINVAL if appropriate. |Don't permit domains other than the hardware or control domain to |allocate node-constrained memory. | |This is XSA-231. | |Reported-by: Matthew Daley |Signed-off-by: George Dunlap |Signed-off-by: Jan Beulich |Reviewed-by: Andrew Cooper | |--- xen/common/memory.c.orig |+++ xen/common/memory.c -------------------------- Patching file xen/common/memory.c using Plan A... Hunk #1 succeeded at 384 (offset -6 lines). Hunk #2 succeeded at 481 (offset -6 lines). Hunk #3 succeeded at 505 (offset -6 lines). Hunk #4 succeeded at 858 (offset -6 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/common/page_alloc.c.orig |+++ xen/common/page_alloc.c -------------------------- Patching file xen/common/page_alloc.c using Plan A... Hunk #1 succeeded at 611 (offset -100 lines). done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA232 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA232 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA232,v 1.1 2017/10/17 10:57:34 bouyer Exp $ | |From: Andrew Cooper |Subject: grant_table: fix GNTTABOP_cache_flush handling | |Don't fall over a NULL grant_table pointer when the owner of the domain |is a system domain (DOMID_{XEN,IO} etc). | |This is XSA-232. | |Reported-by: Matthew Daley |Signed-off-by: Andrew Cooper |Reviewed-by: Jan Beulich | |--- xen/common/grant_table.c.orig |+++ xen/common/grant_table.c -------------------------- Patching file xen/common/grant_table.c using Plan A... Hunk #1 succeeded at 3017 (offset -36 lines). done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA234 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA234 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA234,v 1.1 2017/10/17 10:57:34 bouyer Exp $ | |From: Jan Beulich |Subject: gnttab: also validate PTE permissions upon destroy/replace | |In order for PTE handling to match up with the reference counting done |by common code, presence and writability of grant mapping PTEs must |also be taken into account; validating just the frame number is not |enough. This is in particular relevant if a guest fiddles with grant |PTEs via non-grant hypercalls. | |Note that the flags being passed to replace_grant_host_mapping() |already happen to be those of the existing mapping, so no new function |parameter is needed. | |This is XSA-234. | |Reported-by: Andrew Cooper |Signed-off-by: Jan Beulich |Reviewed-by: Andrew Cooper | |--- xen/arch/x86/mm.c.orig |+++ xen/arch/x86/mm.c -------------------------- Patching file xen/arch/x86/mm.c using Plan A... Hunk #1 succeeded at 3930. Hunk #2 succeeded at 3977. Hunk #3 succeeded at 4006. Hunk #4 succeeded at 4074. Hunk #5 succeeded at 4111. Hunk #6 succeeded at 4148. Hunk #7 succeeded at 4245. Hunk #8 succeeded at 4326. done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA237 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA237 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA237,v 1.1 2017/10/17 10:57:34 bouyer Exp $ | |From: Jan Beulich |Subject: x86: don't allow MSI pIRQ mapping on unowned device | |MSI setup should be permitted only for existing devices owned by the |respective guest (the operation may still be carried out by the domain |controlling that guest). | |This is part of XSA-237. | |Reported-by: HW42 |Signed-off-by: Jan Beulich |Reviewed-by: Andrew Cooper | |--- xen/arch/x86/irq.c.orig |+++ xen/arch/x86/irq.c -------------------------- Patching file xen/arch/x86/irq.c using Plan A... Hunk #1 succeeded at 1961. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |From: Jan Beulich |Subject: x86: enforce proper privilege when (un)mapping pIRQ-s | |(Un)mapping of IRQs, just like other RESOURCE__ADD* / RESOURCE__REMOVE* |actions (in FLASK terms) should be XSM_DM_PRIV rather than XSM_TARGET. |This in turn requires bypassing the XSM check in physdev_unmap_pirq() |for the HVM emuirq case just like is being done in physdev_map_pirq(). |The primary goal security wise, however, is to no longer allow HVM |guests, by specifying their own domain ID instead of DOMID_SELF, to |enter code paths intended for PV guest and the control domains of HVM |guests only. | |This is part of XSA-237. | |Reported-by: HW42 |Signed-off-by: Jan Beulich |Reviewed-by: George Dunlap | |--- xen/arch/x86/physdev.c.orig |+++ xen/arch/x86/physdev.c -------------------------- Patching file xen/arch/x86/physdev.c using Plan A... Hunk #1 succeeded at 110. Hunk #2 succeeded at 255. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/include/xsm/dummy.h.orig |+++ xen/include/xsm/dummy.h -------------------------- Patching file xen/include/xsm/dummy.h using Plan A... Hunk #1 succeeded at 446. Hunk #2 succeeded at 458. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |From: Jan Beulich |Subject: x86/MSI: disallow redundant enabling | |At the moment, Xen attempts to allow redundant enabling of MSI by |having pci_enable_msi() return 0, and point to the existing MSI |descriptor, when the msi already exists. | |Unfortunately, if subsequent errors are encountered, the cleanup |paths assume pci_enable_msi() had done full initialization, and |hence undo everything that was assumed to be done by that |function without also undoing other setup that would normally |occur only after that function was called (in map_domain_pirq() |itself). | |Rather than try to make the redundant enabling case work properly, just |forbid it entirely by having pci_enable_msi() return -EEXIST when MSI |is already set up. | |This is part of XSA-237. | |Reported-by: HW42 |Signed-off-by: Jan Beulich |Reviewed-by: Andrew Cooper |Reviewed-by: George Dunlap | |--- xen/arch/x86/msi.c.orig |+++ xen/arch/x86/msi.c -------------------------- Patching file xen/arch/x86/msi.c using Plan A... Hunk #1 succeeded at 1050. Hunk #2 succeeded at 1117. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |From: Jan Beulich |Subject: x86/IRQ: conditionally preserve irq <-> pirq mapping on map error paths | |Mappings that had been set up before should not be torn down when |handling unrelated errors. | |This is part of XSA-237. | |Reported-by: HW42 |Signed-off-by: Jan Beulich |Reviewed-by: George Dunlap | |--- xen/arch/x86/irq.c.orig |+++ xen/arch/x86/irq.c -------------------------- Patching file xen/arch/x86/irq.c using Plan A... Hunk #1 succeeded at 1249. Hunk #2 succeeded at 1293. Hunk #3 succeeded at 1904. Hunk #4 succeeded at 1948. Hunk #5 succeeded at 2023. Hunk #6 succeeded at 2059. Hunk #7 succeeded at 2083. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/arch/x86/physdev.c.orig |+++ xen/arch/x86/physdev.c -------------------------- Patching file xen/arch/x86/physdev.c using Plan A... Hunk #1 succeeded at 185. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/include/asm-x86/msi.h.orig |+++ xen/include/asm-x86/msi.h -------------------------- Patching file xen/include/asm-x86/msi.h using Plan A... Hunk #1 succeeded at 55. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |From: Jan Beulich |Subject: x86/FLASK: fix unmap-domain-IRQ XSM hook | |The caller and the FLASK implementation of xsm_unmap_domain_irq() |disagreed about what the "data" argument points to in the MSI case: |Change both sides to pass/take a PCI device. | |This is part of XSA-237. | |Signed-off-by: Jan Beulich |Reviewed-by: Andrew Cooper | |--- xen/arch/x86/irq.c.orig |+++ xen/arch/x86/irq.c -------------------------- Patching file xen/arch/x86/irq.c using Plan A... Hunk #1 succeeded at 2141. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/xsm/flask/hooks.c.orig |+++ xen/xsm/flask/hooks.c -------------------------- Patching file xen/xsm/flask/hooks.c using Plan A... Hunk #1 succeeded at 897. done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA238 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA238 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA238,v 1.1 2017/10/17 10:57:34 bouyer Exp $ | |From: XenProject Security Team |Subject: x86/ioreq server: correctly handle bogus | XEN_DMOP_{,un}map_io_range_to_ioreq_server arguments | |Misbehaving device model can pass incorrect XEN_DMOP_map/ |unmap_io_range_to_ioreq_server arguments, namely end < start when |specifying address range. When this happens we hit ASSERT(s <= e) in |rangeset_contains_range()/rangeset_overlaps_range() with debug builds. |Production builds will not trap right away but may misbehave later |while handling such bogus ranges. | |This is XSA-238. | |Signed-off-by: Vitaly Kuznetsov |Reviewed-by: Jan Beulich |--- | xen/arch/x86/hvm/hvm.c | 6 ++++++ | 1 file changed, 6 insertions(+) | |diff --git a/xen/arch/x86/hvm/ioreq.c b/xen/arch/x86/hvm/ioreq.c |index b2a8b0e986..8c8bf1f0ec 100644 |--- xen/arch/x86/hvm/hvm.c.orig |+++ xen/arch/x86/hvm/hvm.c -------------------------- Patching file xen/arch/x86/hvm/hvm.c using Plan A... Hunk #1 succeeded at 1271. Hunk #2 succeeded at 1325. done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA239 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA239 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA239,v 1.1 2017/10/17 10:57:34 bouyer Exp $ | |From: Jan Beulich |Subject: x86/HVM: prefill partially used variable on emulation paths | |Certain handlers ignore the access size (vioapic_write() being the |example this was found with), perhaps leading to subsequent reads |seeing data that wasn't actually written by the guest. For |consistency and extra safety also do this on the read path of |hvm_process_io_intercept(), even if this doesn't directly affect what |guests get to see, as we've supposedly already dealt with read handlers |leaving data completely unitialized. | |This is XSA-239. | |Reported-by: Roger Pau Monné |Reviewed-by: Roger Pau Monné |Signed-off-by: Jan Beulich | |--- xen/arch/x86/hvm/emulate.c.orig |+++ xen/arch/x86/hvm/emulate.c -------------------------- Patching file xen/arch/x86/hvm/emulate.c using Plan A... Hunk #1 succeeded at 106 (offset -23 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/arch/x86/hvm/intercept.c.orig |+++ xen/arch/x86/hvm/intercept.c -------------------------- Patching file xen/arch/x86/hvm/intercept.c using Plan A... Hunk #1 succeeded at 128 (offset 1 line). Hunk #2 succeeded at 164 (offset 2 lines). done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA240 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA240 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA240,v 1.2 2017/12/15 14:00:44 bouyer Exp $ | |From ce31198dd811479da34dfb66315f399dc4b98055 Mon Sep 17 00:00:00 2001 |From: Jan Beulich |Date: Thu, 28 Sep 2017 15:17:28 +0100 |Subject: [PATCH 1/2] x86: limit linear page table use to a single level | |That's the only way that they're meant to be used. Without such a |restriction arbitrarily long chains of same-level page tables can be |built, tearing down of which may then cause arbitrarily deep recursion, |causing a stack overflow. To facilitate this restriction, a counter is |being introduced to track both the number of same-level entries in a |page table as well as the number of uses of a page table in another |same-level one (counting into positive and negative direction |respectively, utilizing the fact that both counts can't be non-zero at |the same time). | |Note that the added accounting introduces a restriction on the number |of times a page can be used in other same-level page tables - more than |32k of such uses are no longer possible. | |Note also that some put_page_and_type[_preemptible]() calls are |replaced with open-coded equivalents. This seemed preferrable to |adding "parent_table" to the matrix of functions. | |Note further that cross-domain same-level page table references are no |longer permitted (they probably never should have been). | |This is XSA-240. | |Reported-by: Jann Horn |Signed-off-by: Jan Beulich |Signed-off-by: George Dunlap |--- | xen/arch/x86/domain.c | 1 + | xen/arch/x86/mm.c | 171 ++++++++++++++++++++++++++++++++++++++----- | xen/include/asm-x86/domain.h | 2 + | xen/include/asm-x86/mm.h | 25 +++++-- | 4 files changed, 175 insertions(+), 24 deletions(-) | |diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c |index bfe614d7b7..23d034fa8d 100644 |--- xen/arch/x86/domain.c.orig |+++ xen/arch/x86/domain.c -------------------------- Patching file xen/arch/x86/domain.c using Plan A... Hunk #1 succeeded at 1131. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c |index 20d963cb22..81074aa473 100644 |--- xen/arch/x86/mm.c.orig |+++ xen/arch/x86/mm.c -------------------------- Patching file xen/arch/x86/mm.c using Plan A... Hunk #1 succeeded at 660. Hunk #2 succeeded at 744. Hunk #3 succeeded at 780. Hunk #4 succeeded at 1206. Hunk #5 succeeded at 1278. Hunk #6 succeeded at 1316. Hunk #7 succeeded at 1346. Hunk #8 succeeded at 1559. Hunk #9 succeeded at 1652. Hunk #10 succeeded at 2401. Hunk #11 succeeded at 2450. Hunk #12 succeeded at 2478. Hunk #13 succeeded at 2519. Hunk #14 succeeded at 2660. Hunk #15 succeeded at 2672. Hunk #16 succeeded at 2688. Hunk #17 succeeded at 2894. Hunk #18 succeeded at 3058. Hunk #19 succeeded at 3304. Hunk #20 succeeded at 3340. Hunk #21 succeeded at 3421. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/xen/include/asm-x86/domain.h b/xen/include/asm-x86/domain.h |index a2d4f74696..4279549c28 100644 |--- xen/include/asm-x86/domain.h.orig |+++ xen/include/asm-x86/domain.h -------------------------- Patching file xen/include/asm-x86/domain.h using Plan A... Hunk #1 succeeded at 512. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/xen/include/asm-x86/mm.h b/xen/include/asm-x86/mm.h |index b4299fddea..4191e13112 100644 |--- xen/include/asm-x86/mm.h.orig |+++ xen/include/asm-x86/mm.h -------------------------- Patching file xen/include/asm-x86/mm.h using Plan A... Hunk #1 succeeded at 124. Hunk #2 succeeded at 152. Hunk #3 succeeded at 214. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |-- |2.14.1 | |From eeea00c427376c269ffa34587f16fa1182d8c29d Mon Sep 17 00:00:00 2001 |From: George Dunlap |Date: Fri, 22 Sep 2017 11:46:55 +0100 |Subject: [PATCH 2/2] x86/mm: Disable PV linear pagetables by default | |Allowing pagetables to point to other pagetables of the same level |(often called 'linear pagetables') has been included in Xen since its |inception. But it is not used by the most common PV guests (Linux, |NetBSD, minios), and has been the source of a number of subtle |reference-counting bugs. | |Add a command-line option to control whether PV linear pagetables are |allowed (disabled by default). | |Reported-by: Jann Horn |Signed-off-by: George Dunlap |Reviewed-by: Andrew Cooper |--- |Changes since v2: |- s/_/-/; in command-line option |- Added __read_mostly |--- | docs/misc/xen-command-line.markdown | 15 +++++++++++++++ | xen/arch/x86/mm.c | 9 +++++++++ | 2 files changed, 24 insertions(+) | |diff --git a/docs/misc/xen-command-line.markdown b/docs/misc/xen-command-line.markdown |index d99a20a44b..c91acaa464 100644 |--- docs/misc/xen-command-line.markdown.orig |+++ docs/misc/xen-command-line.markdown -------------------------- Patching file docs/misc/xen-command-line.markdown using Plan A... Hunk #1 succeeded at 1231. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c |index 81074aa473..75dd077046 100644 |--- xen/arch/x86/mm.c.orig |+++ xen/arch/x86/mm.c -------------------------- Patching file xen/arch/x86/mm.c using Plan A... Hunk #1 succeeded at 727. Hunk #2 succeeded at 739. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |-- |2.14.1 | |From: Jan Beulich |Subject: x86: don't wrongly trigger linear page table assertion | |_put_page_type() may do multiple iterations until its cmpxchg() |succeeds. It invokes set_tlbflush_timestamp() on the first |iteration, however. Code inside the function takes care of this, but |- the assertion in _put_final_page_type() would trigger on the second | iteration if time stamps in a debug build are permitted to be | sufficiently much wider than the default 6 bits (see WRAP_MASK in | flushtlb.c), |- it returning -EINTR (for a continuation to be scheduled) would leave | the page inconsistent state (until the re-invocation completes). |Make the set_tlbflush_timestamp() invocation conditional, bypassing it |(for now) only in the case we really can't tolerate the stamp to be |stored. | |This is part of XSA-240. | |Signed-off-by: Jan Beulich |Reviewed-by: George Dunlap | |--- xen/arch/x86/mm.c.orig |+++ xen/arch/x86/mm.c |--- xen/arch/x86/mm.c.orig 2017-12-15 10:18:25.000000000 +0100 |+++ xen/arch/x86/mm.c 2017-12-15 10:20:53.000000000 +0100 -------------------------- Patching file xen/arch/x86/mm.c using Plan A... Hunk #1 succeeded at 2494. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |From: Jan Beulich |Subject: x86: don't wrongly trigger linear page table assertion (2) | |_put_final_page_type(), when free_page_type() has exited early to allow |for preemption, should not update the time stamp, as the page continues |to retain the typ which is in the process of being unvalidated. I can't |see why the time stamp update was put on that path in the first place |(albeit it may well have been me who had put it there years ago). | |This is part of XSA-240. | |Signed-off-by: Jan Beulich |Reviewed-by: | |--- xen/arch/x86/mm.c.orig 2017-12-15 10:20:53.000000000 +0100 |+++ xen/arch/x86/mm.c 2017-12-15 10:25:32.000000000 +0100 -------------------------- Patching file xen/arch/x86/mm.c using Plan A... Hunk #1 succeeded at 2441. done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA241 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA241 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA241,v 1.2 2017/12/15 14:00:44 bouyer Exp $ | |x86: don't store possibly stale TLB flush time stamp | |While the timing window is extremely narrow, it is theoretically |possible for an update to the TLB flush clock and a subsequent flush |IPI to happen between the read and write parts of the update of the |per-page stamp. Exclude this possibility by disabling interrupts |across the update, preventing the IPI to be serviced in the middle. | |This is XSA-241. | |Reported-by: Jann Horn |Suggested-by: George Dunlap |Signed-off-by: Jan Beulich |Reviewed-by: George Dunlap | |--- xen/arch/arm/smp.c.orig |+++ xen/arch/arm/smp.c -------------------------- Patching file xen/arch/arm/smp.c using Plan A... Hunk #1 succeeded at 1. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/arch/x86/mm.c.orig |+++ xen/arch/x86/mm.c -------------------------- Patching file xen/arch/x86/mm.c using Plan A... Hunk #1 succeeded at 2433 (offset -7 lines). Hunk #2 succeeded at 2513 (offset 3 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/arch/x86/mm/shadow/common.c.orig |+++ xen/arch/x86/mm/shadow/common.c -------------------------- Patching file xen/arch/x86/mm/shadow/common.c using Plan A... Hunk #1 succeeded at 1580 (offset 116 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/common/page_alloc.c.orig |+++ xen/common/page_alloc.c -------------------------- Patching file xen/common/page_alloc.c using Plan A... Hunk #1 succeeded at 878 (offset -82 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/include/asm-arm/flushtlb.h.orig |+++ xen/include/asm-arm/flushtlb.h -------------------------- Patching file xen/include/asm-arm/flushtlb.h using Plan A... Hunk #1 succeeded at 14 (offset 2 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/include/asm-x86/flushtlb.h.orig |+++ xen/include/asm-x86/flushtlb.h -------------------------- Patching file xen/include/asm-x86/flushtlb.h using Plan A... Hunk #1 succeeded at 24 (offset 1 line). done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA242 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA242 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA242,v 1.1 2017/10/17 10:57:34 bouyer Exp $ | |From: Jan Beulich |Subject: x86: don't allow page_unlock() to drop the last type reference | |Only _put_page_type() does the necessary cleanup, and hence not all |domain pages can be released during guest cleanup (leaving around |zombie domains) if we get this wrong. | |This is XSA-242. | |Signed-off-by: Jan Beulich | |--- xen/arch/x86/mm.c.orig |+++ xen/arch/x86/mm.c -------------------------- Patching file xen/arch/x86/mm.c using Plan A... Hunk #1 succeeded at 1833 (offset -90 lines). Hunk #2 succeeded at 2602 (offset -13 lines). done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA243 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA243 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA243,v 1.1 2017/10/17 10:57:34 bouyer Exp $ | |From: Andrew Cooper |Subject: x86: Disable the use of auto-translated PV guests | |This is a minimal backport of c/s 92942fd3d469 "x86/mm: drop |guest_{map,get_eff}_l1e() hooks" from Xen 4.7, which stated: | | Disallow the unmaintained and presumed broken translated-but-not-external | paging mode combination ... | |It turns out that this mode is insecure to run with, as opposed to just simply |broken. | |This is part of XSA-243. | |Signed-off-by: Andrew Cooper | |diff --git a/xen/arch/x86/mm/paging.c b/xen/arch/x86/mm/paging.c |index dcff4fb..945bb61 100644 |--- xen/arch/x86/mm/paging.c.orig |+++ xen/arch/x86/mm/paging.c -------------------------- Patching file xen/arch/x86/mm/paging.c using Plan A... Hunk #1 succeeded at 835. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |From: Andrew Cooper |Subject: x86/shadow: Don't create self-linear shadow mappings for 4-level translated guests | |When initially creating a monitor table for 4-level translated guests, don't |install a shadow-linear mapping. This mapping is actually self-linear, and |trips up the writeable heuristic logic into following Xen's mappings, not the |guests' shadows it was expecting to follow. | |A consequence of this is that sh_guess_wrmap() needs to cope with there being |no shadow-linear mapping present, which in practice occurs once each time a |vcpu switches to 4-level paging from a different paging mode. | |An appropriate shadow-linear slot will be inserted into the monitor table |either while constructing lower level monitor tables, or by sh_update_cr3(). | |While fixing this, clarify the safety of the other mappings. Despite |appearing unsafe, it is correct to create a guest-linear mapping for |translated domains; this is self-linear and doesn't point into the translated |domain. Drop a dead clause for translate != external guests. | |This is part of XSA-243. | |Signed-off-by: Andrew Cooper |Acked-by: Tim Deegan | |diff --git a/xen/arch/x86/mm/shadow/multi.c b/xen/arch/x86/mm/shadow/multi.c |index c34ebe0..cb8ddde 100644 |--- xen/arch/x86/mm/shadow/multi.c.orig |+++ xen/arch/x86/mm/shadow/multi.c -------------------------- Patching file xen/arch/x86/mm/shadow/multi.c using Plan A... Hunk #1 succeeded at 1456. Hunk #2 succeeded at 4282. done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA244 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA244 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA244,v 1.1 2017/10/17 10:57:34 bouyer Exp $ | |From: Andrew Cooper |Subject: x86/cpu: fix IST handling during PCPU bringup | |Clear IST references in newly allocated IDTs. Nothing good will come of |having them set before the TSS is suitably constructed (although the chances |of the CPU surviving such an IST interrupt/exception is extremely slim). | |Uniformly set the IST references after the TSS is in place. This fixes an |issue on AMD hardware, where onlining a PCPU while PCPU0 is in HVM context |will cause IST_NONE to be copied into the new IDT, making that PCPU vulnerable |to privilege escalation from PV guests until it subsequently schedules an HVM |guest. | |This is XSA-244. | |Signed-off-by: Andrew Cooper |Reviewed-by: Jan Beulich | |--- xen/arch/x86/cpu/common.c.orig |+++ xen/arch/x86/cpu/common.c -------------------------- Patching file xen/arch/x86/cpu/common.c using Plan A... Hunk #1 succeeded at 558. Hunk #2 succeeded at 605. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/arch/x86/smpboot.c.orig |+++ xen/arch/x86/smpboot.c -------------------------- Patching file xen/arch/x86/smpboot.c using Plan A... Hunk #1 succeeded at 749. done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA246 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA246 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA246,v 1.1 2017/12/15 14:00:44 bouyer Exp $ | |From: Julien Grall |Subject: x86/pod: prevent infinite loop when shattering large pages | |When populating pages, the PoD may need to split large ones using |p2m_set_entry and request the caller to retry (see ept_get_entry for |instance). | |p2m_set_entry may fail to shatter if it is not possible to allocate |memory for the new page table. However, the error is not propagated |resulting to the callers to retry infinitely the PoD. | |Prevent the infinite loop by return false when it is not possible to |shatter the large mapping. | |This is XSA-246. | |Signed-off-by: Julien Grall |Signed-off-by: Jan Beulich |Reviewed-by: George Dunlap | |--- xen/arch/x86/mm/p2m-pod.c.orig |+++ xen/arch/x86/mm/p2m-pod.c -------------------------- Patching file xen/arch/x86/mm/p2m-pod.c using Plan A... Hunk #1 succeeded at 1045 (offset -28 lines). Hunk #2 succeeded at 1077 (offset -28 lines). Hunk #3 succeeded at 1127 (offset -28 lines). done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA247 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA247 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA247,v 1.1 2017/12/15 14:00:44 bouyer Exp $ | |From 6208d2d761ca4cec3560322222532c4a5ba1b375 Mon Sep 17 00:00:00 2001 |From: George Dunlap |Date: Fri, 10 Nov 2017 16:53:54 +0000 |Subject: [PATCH 1/2] p2m: Always check to see if removing a p2m entry actually | worked | |The PoD zero-check functions speculatively remove memory from the p2m, |then check to see if it's completely zeroed, before putting it in the |cache. | |Unfortunately, the p2m_set_entry() calls may fail if the underlying |pagetable structure needs to change and the domain has exhausted its |p2m memory pool: for instance, if we're removing a 2MiB region out of |a 1GiB entry (in the p2m_pod_zero_check_superpage() case), or a 4k |region out of a 2MiB or larger entry (in the p2m_pod_zero_check() |case); and the return value is not checked. | |The underlying mfn will then be added into the PoD cache, and at some |point mapped into another location in the p2m. If the guest |afterwards ballons out this memory, it will be freed to the hypervisor |and potentially reused by another domain, in spite of the fact that |the original domain still has writable mappings to it. | |There are several places where p2m_set_entry() shouldn't be able to |fail, as it is guaranteed to write an entry of the same order that |succeeded before. Add a backstop of crashing the domain just in case, |and an ASSERT_UNREACHABLE() to flag up the broken assumption on debug |builds. | |While we're here, use PAGE_ORDER_2M rather than a magic constant. | |This is part of XSA-247. | |Reported-by: George Dunlap |Signed-off-by: George Dunlap |Reviewed-by: Jan Beulich |--- |v4: |- Removed some training whitespace |v3: |- Reformat reset clause to be more compact |- Make sure to set map[i] = NULL when unmapping in case we need to bail |v2: |- Crash a domain if a p2m_set_entry we think cannot fail fails anyway. |--- | xen/arch/x86/mm/p2m-pod.c | 76 +++++++++++++++++++++++++++++++++++++---------- | 1 file changed, 60 insertions(+), 16 deletions(-) | |diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c |index 519b80cc3d..b1f0abe02d 100644 |--- xen/arch/x86/mm/p2m-pod.c.orig |+++ xen/arch/x86/mm/p2m-pod.c -------------------------- Patching file xen/arch/x86/mm/p2m-pod.c using Plan A... Hunk #1 succeeded at 729. Hunk #2 succeeded at 787. Hunk #3 succeeded at 855. Hunk #4 succeeded at 895. Hunk #5 succeeded at 937. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |-- |2.15.0 | |From d65a029d34e3d6157c87ac343dc8eefa1b12818e Mon Sep 17 00:00:00 2001 |From: George Dunlap |Date: Fri, 10 Nov 2017 16:53:55 +0000 |Subject: [PATCH 2/2] p2m: Check return value of p2m_set_entry() when | decreasing reservation | |If the entire range specified to p2m_pod_decrease_reservation() is marked |populate-on-demand, then it will make a single p2m_set_entry() call, |reducing its PoD entry count. | |Unfortunately, in the right circumstances, this p2m_set_entry() call |may fail. It that case, repeated calls to decrease_reservation() may |cause p2m->pod.entry_count to fall below zero, potentially tripping |over BUG_ON()s to the contrary. | |Instead, check to see if the entry succeeded, and return false if not. |The caller will then call guest_remove_page() on the gfns, which will |return -EINVAL upon finding no valid memory there to return. | |Unfortunately if the order > 0, the entry may have partially changed. |A domain_crash() is probably the safest thing in that case. | |Other p2m_set_entry() calls in the same function should be fine, |because they are writing the entry at its current order. Nonetheless, |check the return value and crash if our assumption turns otu to be |wrong. | |This is part of XSA-247. | |Reported-by: George Dunlap |Signed-off-by: George Dunlap |Reviewed-by: Jan Beulich |--- |v2: Crash the domain if we're not sure it's safe (or if we think it |can't happen) |--- | xen/arch/x86/mm/p2m-pod.c | 42 +++++++++++++++++++++++++++++++++--------- | 1 file changed, 33 insertions(+), 9 deletions(-) | |diff --git a/xen/arch/x86/mm/p2m-pod.c b/xen/arch/x86/mm/p2m-pod.c |index b1f0abe02d..9324f16c91 100644 |--- xen/arch/x86/mm/p2m-pod.c.orig |+++ xen/arch/x86/mm/p2m-pod.c -------------------------- Patching file xen/arch/x86/mm/p2m-pod.c using Plan A... Hunk #1 succeeded at 559. Hunk #2 succeeded at 607. Hunk #3 succeeded at 627. Hmm... Ignoring the trailing garbage. done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA248 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA248 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA248,v 1.1 2017/12/15 14:00:44 bouyer Exp $ | |From: Jan Beulich |Subject: x86/mm: don't wrongly set page ownership | |PV domains can obtain mappings of any pages owned by the correct domain, |including ones that aren't actually assigned as "normal" RAM, but used |by Xen internally. At the moment such "internal" pages marked as owned |by a guest include pages used to track logdirty bits, as well as p2m |pages and the "unpaged pagetable" for HVM guests. Since the PV memory |management and shadow code conflict in their use of struct page_info |fields, and since shadow code is being used for log-dirty handling for |PV domains, pages coming from the shadow pool must, for PV domains, not |have the domain set as their owner. | |While the change could be done conditionally for just the PV case in |shadow code, do it unconditionally (and for consistency also for HAP), |just to be on the safe side. | |There's one special case though for shadow code: The page table used for |running a HVM guest in unpaged mode is subject to get_page() (in |set_shadow_status()) and hence must have its owner set. | |This is XSA-248. | |Signed-off-by: Jan Beulich |Reviewed-by: Tim Deegan |Reviewed-by: George Dunlap | |--- xen/arch/x86/mm/hap/hap.c.orig |+++ xen/arch/x86/mm/hap/hap.c -------------------------- Patching file xen/arch/x86/mm/hap/hap.c using Plan A... Hunk #1 succeeded at 283. Hunk #2 succeeded at 298. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/arch/x86/mm/shadow/common.c.orig |+++ xen/arch/x86/mm/shadow/common.c -------------------------- Patching file xen/arch/x86/mm/shadow/common.c using Plan A... Hunk #1 succeeded at 1619 (offset 46 lines). Hunk #2 succeeded at 3002 (offset -211 lines). Hunk #3 succeeded at 3299 (offset 46 lines). Hunk #4 succeeded at 3155 (offset -211 lines). done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA249 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA249 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA249,v 1.1 2017/12/15 14:00:44 bouyer Exp $ | |From: Jan Beulich |Subject: x86/shadow: fix refcount overflow check | |Commit c385d27079 ("x86 shadow: for multi-page shadows, explicitly track |the first page") reduced the refcount width to 25, without adjusting the |overflow check. Eliminate the disconnect by using a manifest constant. | |Interestingly, up to commit 047782fa01 ("Out-of-sync L1 shadows: OOS |snapshot") the refcount was 27 bits wide, yet the check was already |using 26. | |This is XSA-249. | |Signed-off-by: Jan Beulich |Reviewed-by: George Dunlap |Reviewed-by: Tim Deegan |--- |v2: Simplify expression back to the style it was. | |--- xen/arch/x86/mm/shadow/private.h.orig |+++ xen/arch/x86/mm/shadow/private.h -------------------------- Patching file xen/arch/x86/mm/shadow/private.h using Plan A... Hunk #1 succeeded at 523 (offset -6 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- xen/include/asm-x86/mm.h.orig |+++ xen/include/asm-x86/mm.h -------------------------- Patching file xen/include/asm-x86/mm.h using Plan A... Hunk #1 succeeded at 82. done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA250 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA250 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA250,v 1.1 2017/12/15 14:00:44 bouyer Exp $ | |From: Jan Beulich |Subject: x86/shadow: fix ref-counting error handling | |The old-Linux handling in shadow_set_l4e() mistakenly ORed together the |results of sh_get_ref() and sh_pin(). As the latter failing is not a |correctness problem, simply ignore its return value. | |In sh_set_toplevel_shadow() a failing sh_get_ref() must not be |accompanied by installing the entry, despite the domain being crashed. | |This is XSA-250. | |Signed-off-by: Jan Beulich |Reviewed-by: Tim Deegan | |--- xen/arch/x86/mm/shadow/multi.c.orig |+++ xen/arch/x86/mm/shadow/multi.c -------------------------- Patching file xen/arch/x86/mm/shadow/multi.c using Plan A... Hunk #1 succeeded at 894 (offset -29 lines). Hunk #2 succeeded at 909 (offset -29 lines). Hunk #3 succeeded at 3926 (offset -40 lines). done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA251 => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-XSA251 Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-XSA251,v 1.1 2017/12/15 14:00:44 bouyer Exp $ | |From: Jan Beulich |Subject: x86/paging: don't unconditionally BUG() on finding SHARED_M2P_ENTRY | |PV guests can fully control the values written into the P2M. | |This is XSA-251. | |Signed-off-by: Jan Beulich |Reviewed-by: Andrew Cooper | |--- xen/arch/x86/mm/paging.c.orig |+++ xen/arch/x86/mm/paging.c -------------------------- Patching file xen/arch/x86/mm/paging.c using Plan A... Hunk #1 succeeded at 277 (offset 1 line). done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-tools_xentrace_xenalyze.c => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-tools_xentrace_xenalyze.c Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-tools_xentrace_xenalyze.c,v 1.1 2017/02/14 21:38:34 joerg Exp $ | |Based on 28ab9f3d0e7cbb22f5ce77500af7873f6e2d3c59. | |--- tools/xentrace/xenalyze.c.orig 2016-06-20 12:08:22.000000000 +0000 |+++ tools/xentrace/xenalyze.c -------------------------- Patching file tools/xentrace/xenalyze.c using Plan A... Hunk #1 succeeded at 509. Hunk #2 succeeded at 2261. Hunk #3 succeeded at 2308. Hunk #4 succeeded at 2354. Hunk #5 succeeded at 2635. Hunk #6 succeeded at 2659. Hunk #7 succeeded at 2954. Hunk #8 succeeded at 2979. Hunk #9 succeeded at 3545. Hunk #10 succeeded at 3607. Hunk #11 succeeded at 4112. Hunk #12 succeeded at 4141. done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-xen_Makefile => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-xen_Makefile Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-xen_Makefile,v 1.1.1.1 2016/07/04 07:25:13 jnemeth Exp $ | |--- xen/Makefile.orig 2016-02-09 14:44:19.000000000 +0000 |+++ xen/Makefile -------------------------- Patching file xen/Makefile using Plan A... Hunk #1 succeeded at 135. done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-xen_arch_arm_xen.lds.S => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-xen_arch_arm_xen.lds.S Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-xen_arch_arm_xen.lds.S,v 1.1 2017/05/07 21:21:01 joerg Exp $ | |--- xen/arch/arm/xen.lds.S.orig 2016-06-20 12:08:22.000000000 +0000 |+++ xen/arch/arm/xen.lds.S -------------------------- Patching file xen/arch/arm/xen.lds.S using Plan A... Hunk #1 succeeded at 110. done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-xen_arch_x86_Rules.mk => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-xen_arch_x86_Rules.mk Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-xen_arch_x86_Rules.mk,v 1.1.1.1 2016/07/04 07:25:14 jnemeth Exp $ | |--- xen/arch/x86/Rules.mk.orig 2015-01-12 17:53:24.000000000 +0100 |+++ xen/arch/x86/Rules.mk 2015-01-19 12:29:14.000000000 +0100 -------------------------- Patching file xen/arch/x86/Rules.mk using Plan A... Hunk #1 succeeded at 18 (offset -6 lines). done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-xen_arch_x86_alternative.c => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-xen_arch_x86_alternative.c Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-xen_arch_x86_alternative.c,v 1.1 2017/05/07 21:21:01 joerg Exp $ | |--- xen/arch/x86/alternative.c.orig 2016-06-20 12:08:22.000000000 +0000 |+++ xen/arch/x86/alternative.c -------------------------- Patching file xen/arch/x86/alternative.c using Plan A... Hunk #1 succeeded at 38. Hunk #2 succeeded at 62. done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-xen_arch_x86_mm.c => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-xen_arch_x86_mm.c Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-xen_arch_x86_mm.c,v 1.1 2017/02/14 21:38:34 joerg Exp $ | |From e0a97098e20d8fe334b76b37dd6fb0a358a6953c. | |--- xen/arch/x86/mm.c.orig 2017-02-10 22:44:48.124078150 +0000 |+++ xen/arch/x86/mm.c -------------------------- Patching file xen/arch/x86/mm.c using Plan A... Hunk #1 succeeded at 517. done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-xen_arch_x86_xen.lds.S => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-xen_arch_x86_xen.lds.S Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-xen_arch_x86_xen.lds.S,v 1.1 2017/02/14 21:38:34 joerg Exp $ | |From e0a97098e20d8fe334b76b37dd6fb0a358a6953c. | |--- xen/arch/x86/xen.lds.S.orig 2017-02-10 22:45:18.382878546 +0000 |+++ xen/arch/x86/xen.lds.S -------------------------- Patching file xen/arch/x86/xen.lds.S using Plan A... Hunk #1 succeeded at 166. done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-xen_common_efi_boot.c => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-xen_common_efi_boot.c Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-xen_common_efi_boot.c,v 1.1 2017/05/07 21:21:01 joerg Exp $ | |--- xen/common/efi/boot.c.orig 2016-06-20 12:08:22.000000000 +0000 |+++ xen/common/efi/boot.c -------------------------- Patching file xen/common/efi/boot.c using Plan A... Hunk #1 succeeded at 241. done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-xen_common_page__alloc.c => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-xen_common_page__alloc.c Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-xen_common_page__alloc.c,v 1.1.1.1 2016/07/04 07:25:13 jnemeth Exp $ | |--- xen/common/page_alloc.c.orig 2015-09-13 17:37:09.000000000 +0000 |+++ xen/common/page_alloc.c -------------------------- Patching file xen/common/page_alloc.c using Plan A... Hunk #1 succeeded at 1570 (offset 9 lines). done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-xen_drivers_passthrough_vtd_x86_ats.c => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-xen_drivers_passthrough_vtd_x86_ats.c Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-xen_drivers_passthrough_vtd_x86_ats.c,v 1.1.1.1 2016/07/04 07:25:14 jnemeth Exp $ | |--- xen/drivers/passthrough/vtd/x86/ats.c.orig 2015-06-22 13:41:35.000000000 +0000 |+++ xen/drivers/passthrough/vtd/x86/ats.c -------------------------- Patching file xen/drivers/passthrough/vtd/x86/ats.c using Plan A... Hunk #1 succeeded at 133 (offset -1 lines). Hunk #2 succeeded at 145 (offset -1 lines). done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-xen_include_asm-x86_current.h => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-xen_include_asm-x86_current.h Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-xen_include_asm-x86_current.h,v 1.1.1.1 2016/07/04 07:25:13 jnemeth Exp $ | |--- xen/include/asm-x86/current.h.orig 2015-01-30 12:45:05.000000000 +0000 |+++ xen/include/asm-x86/current.h -------------------------- Patching file xen/include/asm-x86/current.h using Plan A... Hunk #1 succeeded at 47 (offset 22 lines). done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-xen_include_asm-x86_spinlock.h => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-xen_include_asm-x86_spinlock.h Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-xen_include_asm-x86_spinlock.h,v 1.1 2017/02/14 21:38:34 joerg Exp $ | |From c86aa9a250ca0c87760b369f295f67ae01542fa9. | |--- xen/include/asm-x86/spinlock.h.orig 2017-02-10 22:33:31.337508849 +0000 |+++ xen/include/asm-x86/spinlock.h -------------------------- Patching file xen/include/asm-x86/spinlock.h using Plan A... Hunk #1 succeeded at 2. done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-xen_include_xen_init.h => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-xen_include_xen_init.h Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-xen_include_xen_init.h,v 1.1 2017/05/07 21:21:01 joerg Exp $ | |--- xen/include/xen/init.h.orig 2016-06-20 12:08:22.000000000 +0000 |+++ xen/include/xen/init.h -------------------------- Patching file xen/include/xen/init.h using Plan A... Hunk #1 succeeded at 11. done => Verifying /data/pkgsrc/sysutils/xenkernel46/patches/patch-xen_include_xen_lib.h => Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel46/patches/patch-xen_include_xen_lib.h Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |$NetBSD: patch-xen_include_xen_lib.h,v 1.1.1.1 2016/07/04 07:25:13 jnemeth Exp $ | |--- xen/include/xen/lib.h.orig 2015-06-22 15:41:35.000000000 +0200 |+++ xen/include/xen/lib.h 2015-06-23 18:32:26.000000000 +0200 -------------------------- Patching file xen/include/xen/lib.h using Plan A... Hunk #1 succeeded at 32 (offset -12 lines). done ===> Creating toolchain wrappers for xenkernel46-4.6.6nb3