=> 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 <jbeulich@suse.com>
|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 <jbeulich@suse.com>
|
|--- 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 <jbeulich@suse.com>
|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 <andrew.cooper3@citrix.com>
|Signed-off-by: Jan Beulich <jbeulich@suse.com>
|Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
|
|--- 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 <andrew.cooper3@citrix.com>
|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 <andrew.cooper3@citrix.com>
|Reviewed-by: Jan Beulich <jbeulich@suse.com>
|---
| 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 <jbeulich@suse.com>
|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 <ian.jackson@eu.citrix.com>
|Signed-off-by: Jan Beulich <jbeulich@suse.com>
|Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
|---
| 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 <jbeulich@suse.com>
|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 <jbeulich@suse.com>
|Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
|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 <george.dunlap@citrix.com>
|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 <mattd@bugfuzz.com>
|Signed-off-by: George Dunlap <george.dunlap@citrix.com>
|Signed-off-by: Jan Beulich <jbeulich@suse.com>
|Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
|
|--- 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 <andrew.cooper3@citrix.com>
|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 <mattd@bugfuzz.com>
|Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
|Reviewed-by: Jan Beulich <jbeulich@suse.com>
|
|--- 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 <jbeulich@suse.com>
|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 <andrew.cooper3@citrix.com>
|Signed-off-by: Jan Beulich <jbeulich@suse.com>
|Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
|
|--- 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 <jbeulich@suse.com>
|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 <hw42@ipsumj.de>
|Signed-off-by: Jan Beulich <jbeulich@suse.com>
|Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
|
|--- 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 <jbeulich@suse.com>
|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 <hw42@ipsumj.de>
|Signed-off-by: Jan Beulich <jbeulich@suse.com>
|Reviewed-by: George Dunlap <george.dunlap@citrix.com>
|
|--- 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 <jbeulich@suse.com>
|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 <hw42@ipsumj.de>
|Signed-off-by: Jan Beulich <jbeulich@suse.com>
|Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
|Reviewed-by: George Dunlap <george.dunlap@citrix.com>
|
|--- 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 <jbeulich@suse.com>
|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 <hw42@ipsumj.de>
|Signed-off-by: Jan Beulich <jbeulich@suse.com>
|Reviewed-by: George Dunlap <george.dunlap@citrix.com>
|
|--- 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 <jbeulich@suse.com>
|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 <jbeulich@suse.com>
|Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
|
|--- 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 <security@xenproject.org>
|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 <vkuznets@redhat.com>
|Reviewed-by: Jan Beulich <jbeulich@suse.com>
|---
| 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 <jbeulich@suse.com>
|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é <roger.pau@citrix.com>
|Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
|Signed-off-by: Jan Beulich <jbeulich@suse.com>
|
|--- 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 <jbeulich@suse.com>
|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 <jannh@google.com>
|Signed-off-by: Jan Beulich <jbeulich@suse.com>
|Signed-off-by: George Dunlap <george.dunlap@citrix.com>
|---
| 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 <george.dunlap@citrix.com>
|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 <jannh@google.com>
|Signed-off-by: George Dunlap <george.dunlap@citrix.com>
|Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
|---
|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 <jbeulich@suse.com>
|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 <jbeulich@suse.com>
|Reviewed-by: George Dunlap <george.dunlap@citrix.com>
|
|--- 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 <jbeulich@suse.com>
|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 <jbeulich@suse.com>
|Reviewed-by: <George Dunlap <george.dunlap.com>
|
|--- 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 <jannh@google.com>
|Suggested-by: George Dunlap <george.dunlap@citrix.com>
|Signed-off-by: Jan Beulich <jbeulich@suse.com>
|Reviewed-by: George Dunlap <george.dunlap@citrix.com>
|
|--- 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 <jbeulich@suse.com>
|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 <jbeulich@suse.com>
|
|--- 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 <andrew.cooper3@citrix.com>
|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 <andrew.cooper3@citrix.com>
|
|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 <andrew.cooper3@citrix.com>
|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 <andrew.cooper3@citrix.com>
|Acked-by: Tim Deegan <tim@xen.org>
|
|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 <andrew.cooper3@citrix.com>
|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 <andrew.cooper3@citrix.com>
|Reviewed-by: Jan Beulich <jbeulich@suse.com>
|
|--- 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 <julien.grall@linaro.org>
|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 <julien.grall@linaro.org>
|Signed-off-by: Jan Beulich <jbeulich@suse.com>
|Reviewed-by: George Dunlap <george.dunlap@citrix.com>
|
|--- 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 <george.dunlap@citrix.com>
|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 <george.dunlap.com>
|Signed-off-by: George Dunlap <george.dunlap@citrix.com>
|Reviewed-by: Jan Beulich <jbeulich@suse.com>
|---
|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 <george.dunlap@citrix.com>
|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 <george.dunlap.com>
|Signed-off-by: George Dunlap <george.dunlap@citrix.com>
|Reviewed-by: Jan Beulich <jbeulich@suse.com>
|---
|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 <jbeulich@suse.com>
|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 <jbeulich@suse.com>
|Reviewed-by: Tim Deegan <tim@xen.org>
|Reviewed-by: George Dunlap <george.dunlap@citrix.com>
|
|--- 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 <jbeulich@suse.com>
|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 <jbeulich@suse.com>
|Reviewed-by: George Dunlap <george.dunlap@citrix.com>
|Reviewed-by: Tim Deegan <tim@xen.org>
|---
|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 <jbeulich@suse.com>
|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 <jbeulich@suse.com>
|Reviewed-by: Tim Deegan <tim@xen.org>
|
|--- 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 <jbeulich@suse.com>
|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 <jbeulich@suse.com>
|Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
|
|--- 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