=> 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.2.5.tar.gz
=> Checksum RMD160 OK for xen-4.2.5.tar.gz
=> Checksum SHA512 OK for xen-4.2.5.tar.gz
===> Installing dependencies for xenkernel42-4.2.5nb16
==========================================================================
The following variables will affect the build process of this package,
xenkernel42-4.2.5nb16.  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.17nb2
=> Build dependency cwrappers>=20150314: found cwrappers-20180325
===> Overriding tools for xenkernel42-4.2.5nb16
===> Extracting for xenkernel42-4.2.5nb16
===> Patching for xenkernel42-4.2.5nb16
=> Applying pkgsrc patches for xenkernel42-4.2.5nb16
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2014-8594
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2014-8594
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-CVE-2014-8594,v 1.1 2014/11/27 15:20:31 bouyer Exp $
|
|x86: don't allow page table updates on non-PV page tables in do_mmu_update()
|
|paging_write_guest_entry() and paging_cmpxchg_guest_entry() aren't
|consistently supported for non-PV guests (they'd deref NULL for PVH or
|non-HAP HVM ones). Don't allow respective MMU_* operations on the
|page tables of such domains.
|
|This is XSA-109.
|
|Signed-off-by: Jan Beulich <jbeulich@suse.com>
|Acked-by: Tim Deegan <tim@xen.org>
|
|--- 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 3794 (offset -6 lines).
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2014-8595
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2014-8595
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-CVE-2014-8595,v 1.1 2014/11/27 15:20:31 bouyer Exp $
|
|x86emul: enforce privilege level restrictions when loading CS
|
|Privilege level checks were basically missing for the CS case, the
|only check that was done (RPL == DPL for nonconforming segments)
|was solely covering a single special case (return to non-conforming
|segment).
|
|Additionally in long mode the L bit set requires the D bit to be clear,
|as was recently pointed out for KVM by Nadav Amit
|<namit@cs.technion.ac.il>.
|
|Finally we also need to force the loaded selector's RPL to CPL (at
|least as long as lret/retf emulation doesn't support privilege level
|changes).
|
|This is XSA-110.
|
|Signed-off-by: Jan Beulich <jbeulich@suse.com>
|Reviewed-by: Tim Deegan <tim@xen.org>
|
|--- xen/arch/x86/x86_emulate/x86_emulate.c.orig
|+++ xen/arch/x86/x86_emulate/x86_emulate.c
--------------------------
Patching file xen/arch/x86/x86_emulate/x86_emulate.c using Plan A...
Hunk #1 succeeded at 1107.
Hunk #2 succeeded at 1179.
Hunk #3 succeeded at 1260.
Hunk #4 succeeded at 1269.
Hunk #5 succeeded at 1866.
Hunk #6 succeeded at 2239 (offset 3 lines).
Hunk #7 succeeded at 2320 (offset 3 lines).
Hunk #8 succeeded at 2543 (offset 3 lines).
Hunk #9 succeeded at 2617 (offset 3 lines).
Hunk #10 succeeded at 2660 (offset -1 lines).
Hunk #11 succeeded at 3294 (offset 3 lines).
Hunk #12 succeeded at 3602 (offset -2 lines).
Hunk #13 succeeded at 3688 (offset 3 lines).
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2014-8866
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2014-8866
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-CVE-2014-8866,v 1.1 2014/11/27 15:20:31 bouyer Exp $
|
|x86: limit checks in hypercall_xlat_continuation() to actual arguments
|
|HVM/PVH guests can otherwise trigger the final BUG_ON() in that
|function by entering 64-bit mode, setting the high halves of affected
|registers to non-zero values, leaving 64-bit mode, and issuing a
|hypercall that might get preempted and hence become subject to
|continuation argument translation (HYPERVISOR_memory_op being the only
|one possible for HVM, PVH also having the option of using
|HYPERVISOR_mmuext_op). This issue got introduced when HVM code was
|switched to use compat_memory_op() - neither that nor
|hypercall_xlat_continuation() were originally intended to be used by
|other than PV guests (which can't enter 64-bit mode and hence have no
|way to alter the high halves of 64-bit registers).
|
|This is XSA-111.
|
|Signed-off-by: Jan Beulich <jbeulich@suse.com>
|Reviewed-by: Tim Deegan <tim@xen.org>
|
|--- 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 1921.
Hunk #2 succeeded at 1931.
Hunk #3 succeeded at 1943.
Hunk #4 succeeded at 1971.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- xen/arch/x86/x86_64/compat/mm.c.orig
|+++ xen/arch/x86/x86_64/compat/mm.c
--------------------------
Patching file xen/arch/x86/x86_64/compat/mm.c using Plan A...
Hunk #1 succeeded at 78.
Hunk #2 succeeded at 144.
Hunk #3 succeeded at 379.
Hunk #4 succeeded at 387.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- xen/common/compat/memory.c.orig
|+++ xen/common/compat/memory.c
--------------------------
Patching file xen/common/compat/memory.c using Plan A...
Hunk #1 succeeded at 208.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- xen/include/xen/compat.h.orig
|+++ xen/include/xen/compat.h
--------------------------
Patching file xen/include/xen/compat.h using Plan A...
Hunk #1 succeeded at 192.
Hunk #2 succeeded at 213.
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2014-8867
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2014-8867
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-CVE-2014-8867,v 1.1 2014/11/27 15:20:31 bouyer Exp $
|
|x86/HVM: confine internally handled MMIO to solitary regions
|
|While it is generally wrong to cross region boundaries when dealing
|with MMIO accesses of repeated string instructions (currently only
|MOVS) as that would do things a guest doesn't expect (leaving aside
|that none of these regions would normally be accessed with repeated
|string instructions in the first place), this is even more of a problem
|for all virtual MSI-X page accesses (both msixtbl_{read,write}() can be
|made dereference NULL "entry" pointers this way) as well as undersized
|(1- or 2-byte) LAPIC writes (causing vlapic_read_aligned() to access
|space beyond the one memory page set up for holding LAPIC register
|values).
|
|Since those functions validly assume to be called only with addresses
|their respective checking functions indicated to be okay, it is generic
|code that needs to be fixed to clip the repetition count.
|
|To be on the safe side (and consistent), also do the same for buffered
|I/O intercepts, even if their only client (stdvga) doesn't put the
|hypervisor at risk (i.e. "only" guest misbehavior would result).
|
|This is CVE-2014-8867 / XSA-112.
|
|Signed-off-by: Jan Beulich <jbeulich@suse.com>
|Reviewed-by: Tim Deegan <tim@xen.org>
|
|--- 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 131.
Hunk #2 succeeded at 256.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- xen/arch/x86/hvm/vmsi.c.orig
|+++ xen/arch/x86/hvm/vmsi.c
--------------------------
Patching file xen/arch/x86/hvm/vmsi.c using Plan A...
Hunk #1 succeeded at 236.
Hunk #2 succeeded at 280.
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2014-9030
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2014-9030
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-CVE-2014-9030,v 1.1 2014/11/27 15:20:31 bouyer Exp $
|
|x86/mm: fix a reference counting error in MMU_MACHPHYS_UPDATE
|
|Any domain which can pass the XSM check against a translated guest can cause a
|page reference to be leaked.
|
|While shuffling the order of checks, drop the quite-pointless MEM_LOG().  This
|brings the check in line with similar checks in the vicinity.
|
|Discovered while reviewing the XSA-109/110 followup series.
|
|This is XSA-113.
|
|Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
|Reviewed-by: Jan Beulich <jbeulich@suse.com>
|Reviewed-by: Tim Deegan <tim@xen.org>
|
|--- 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 3911 (offset 292 lines).
Hunk #2 succeeded at 3639 (offset -5 lines).
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-2044
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-2044
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-CVE-2015-2044,v 1.1 2015/03/05 13:44:57 spz Exp $
|
|x86/HVM: return all ones on wrong-sized reads of system device I/O ports
|
|So far the value presented to the guest remained uninitialized.
|
|This is CVE-2015-2044 / XSA-121.
|
|Signed-off-by: Jan Beulich <jbeulich@suse.com>
|Acked-by: Ian Campbell <ian.campbell@citrix.com>
|
|--- xen/arch/x86/hvm/rtc.c.orig	2014-09-02 06:22:57.000000000 +0000
|+++ xen/arch/x86/hvm/rtc.c
--------------------------
Patching file xen/arch/x86/hvm/rtc.c using Plan A...
Hunk #1 succeeded at 619.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- xen/arch/x86/hvm/i8254.c.orig	2014-09-02 06:22:57.000000000 +0000
|+++ xen/arch/x86/hvm/i8254.c
--------------------------
Patching file xen/arch/x86/hvm/i8254.c using Plan A...
Hunk #1 succeeded at 478.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- xen/arch/x86/hvm/pmtimer.c.orig	2014-09-02 06:22:57.000000000 +0000
|+++ xen/arch/x86/hvm/pmtimer.c
--------------------------
Patching file xen/arch/x86/hvm/pmtimer.c using Plan A...
Hunk #1 succeeded at 213.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- xen/arch/x86/hvm/vpic.c.orig	2014-09-02 06:22:57.000000000 +0000
|+++ xen/arch/x86/hvm/vpic.c
--------------------------
Patching file xen/arch/x86/hvm/vpic.c using Plan A...
Hunk #1 succeeded at 324.
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-2045
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-2045
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-CVE-2015-2045,v 1.1 2015/03/05 13:44:57 spz Exp $
|
|pre-fill structures for certain HYPERVISOR_xen_version sub-ops
|
|... avoiding to pass hypervisor stack contents back to the caller
|through space unused by the respective strings.
|
|This is CVE-2015-2045 / XSA-122.
|
|Signed-off-by: Aaron Adams <Aaron.Adams@nccgroup.com>
|Acked-by: Jan Beulich <jbeulich@suse.com>
|Acked-by: Ian Campbell <ian.campbell@citrix.com>
|
|--- xen/common/kernel.c.orig	2014-09-02 06:22:57.000000000 +0000
|+++ xen/common/kernel.c
--------------------------
Patching file xen/common/kernel.c using Plan A...
Hunk #1 succeeded at 216.
Hunk #2 succeeded at 227.
Hunk #3 succeeded at 264.
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-2151
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-2151
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-CVE-2015-2151,v 1.1 2015/03/10 19:50:16 spz Exp $
|
|xsa123-4.3-4.2.patch from upstream:
|
|x86emul: fully ignore segment override for register-only operations
|
|For ModRM encoded instructions with register operands we must not
|overwrite ea.mem.seg (if a - bogus in that case - segment override was
|present) as it aliases with ea.reg.
|
|This is CVE-2015-2151 / XSA-123.
|
|--- xen/arch/x86/x86_emulate/x86_emulate.c.orig	2015-03-10 19:18:09.000000000 +0000
|+++ xen/arch/x86/x86_emulate/x86_emulate.c
--------------------------
Patching file xen/arch/x86/x86_emulate/x86_emulate.c using Plan A...
Hunk #1 succeeded at 1640.
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-2752
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-2752
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-CVE-2015-2752,v 1.1 2015/04/19 13:13:20 spz Exp $
|
|Patch for CVE-2015-2752 aka XSA-125 from
|http://xenbits.xenproject.org/xsa/xsa125-4.2.patch
|
|--- tools/libxc/xc_domain.c.orig	2014-09-02 06:22:57.000000000 +0000
|+++ tools/libxc/xc_domain.c
--------------------------
Patching file tools/libxc/xc_domain.c using Plan A...
Hunk #1 succeeded at 1352.
Hunk #2 succeeded at 1368.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|
|--- xen/arch/x86/domctl.c.orig	2014-09-02 06:22:57.000000000 +0000
|+++ xen/arch/x86/domctl.c
--------------------------
Patching file xen/arch/x86/domctl.c using Plan A...
Hunk #1 succeeded at 865.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|
|--- xen/include/public/domctl.h.orig	2014-09-02 06:22:57.000000000 +0000
|+++ xen/include/public/domctl.h
--------------------------
Patching file xen/include/public/domctl.h using Plan A...
Hunk #1 succeeded at 507.
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-2756
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-2756
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-CVE-2015-2756,v 1.1 2015/04/19 13:13:21 spz Exp $
|
|patch for CVE-2015-2756 aka XSA-126 from
|http://xenbits.xenproject.org/xsa/xsa126-qemut.patch
|
|--- tools/qemu-xen-traditional/hw/pass-through.c.orig	2014-01-09 12:44:42.000000000 +0000
|+++ tools/qemu-xen-traditional/hw/pass-through.c
--------------------------
Patching file tools/qemu-xen-traditional/hw/pass-through.c using Plan A...
Hunk #1 succeeded at 172.
Hunk #2 succeeded at 283.
Hunk #3 succeeded at 1902.
Hunk #4 succeeded at 1922.
Hunk #5 succeeded at 3269.
Hunk #6 succeeded at 3403.
Hunk #7 succeeded at 4184.
Hunk #8 succeeded at 4274.
Hunk #9 succeeded at 4352.
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-3340
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-3340
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-CVE-2015-3340,v 1.1 2015/08/23 16:17:12 spz Exp $
|
|patch for CVE-2015-3340 aka XSA-132 from
|http://xenbits.xen.org/xsa/xsa132-4.2.patch
|
|--- xen/arch/x86/domctl.c.orig	2014-09-02 06:22:57.000000000 +0000
|+++ xen/arch/x86/domctl.c
--------------------------
Patching file xen/arch/x86/domctl.c using Plan A...
Hunk #1 succeeded at 1203 (offset 5 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-CVE-2015-3340,v 1.1 2015/08/23 16:17:12 spz Exp $
|
|--- xen/common/sysctl.c.orig	2014-09-02 06:22:57.000000000 +0000
|+++ xen/common/sysctl.c
--------------------------
Patching file xen/common/sysctl.c using Plan A...
Hunk #1 succeeded at 95.
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-3456
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-3456
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-CVE-2015-3456,v 1.1 2015/06/05 18:18:41 khorben Exp $
|
|fdc: force the fifo access to be in bounds of the allocated buffer
|
|During processing of certain commands such as FD_CMD_READ_ID and
|FD_CMD_DRIVE_SPECIFICATION_COMMAND the fifo memory access could
|get out of bounds leading to memory corruption with values coming
|from the guest.
|
|Fix this by making sure that the index is always bounded by the
|allocated memory.
|
|This is CVE-2015-3456.
|
|Signed-off-by: Petr Matousek <pmatouse@redhat.com>
|Reviewed-by: John Snow <jsnow@redhat.com>
|
|--- tools/qemu-xen/hw/fdc.c.orig
|+++ tools/qemu-xen/hw/fdc.c
--------------------------
Patching file tools/qemu-xen/hw/fdc.c using Plan A...
Hunk #1 succeeded at 1239 (offset -258 lines).
Hunk #2 succeeded at 1248 (offset -258 lines).
Hunk #3 succeeded at 1594 (offset -258 lines).
Hunk #4 succeeded at 1953 (offset -5 lines).
Hunk #5 succeeded at 1746 (offset -261 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- tools/qemu-xen-traditional/hw/fdc.c.orig
|+++ tools/qemu-xen-traditional/hw/fdc.c
--------------------------
Patching file tools/qemu-xen-traditional/hw/fdc.c using Plan A...
Hunk #1 succeeded at 1318.
Hunk #2 succeeded at 1327.
Hunk #3 succeeded at 1673.
Hunk #4 succeeded at 1774.
Hunk #5 succeeded at 1820.
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-4163
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-4163
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-CVE-2015-4163,v 1.1 2015/08/23 16:17:12 spz Exp $
|
|patch for CVE-2015-4163 aka XSA-134 from
|http://xenbits.xen.org/xsa/xsa134.patch
|
|--- xen/common/grant_table.c.orig	2014-09-02 06:22:57.000000000 +0000
|+++ xen/common/grant_table.c
--------------------------
Patching file xen/common/grant_table.c using Plan A...
Hunk #1 succeeded at 2372.
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-4164
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-4164
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-CVE-2015-4164,v 1.1 2015/08/23 16:17:12 spz Exp $
|
|patch for CVE-2015-4164 aka XSA-136 from
|http://xenbits.xen.org/xsa/xsa136.patch
|
|--- xen/arch/x86/x86_64/compat/traps.c.orig	2014-09-02 06:22:57.000000000 +0000
|+++ xen/arch/x86/x86_64/compat/traps.c
--------------------------
Patching file xen/arch/x86/x86_64/compat/traps.c using Plan A...
Hunk #1 succeeded at 114.
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-5307
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-5307
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-CVE-2015-5307,v 1.1 2016/01/07 17:53:58 bouyer Exp $
|
|Patch for CVE-2015-5307 and CVE-2015-8104 aka XSA-156, based on
|http://xenbits.xenproject.org/xsa/xsa156-4.3.patch
|
|--- xen/arch/x86/hvm/svm/svm.c.orig	2014-09-02 08:22:57.000000000 +0200
|+++ xen/arch/x86/hvm/svm/svm.c	2016-01-07 14:30:34.000000000 +0100
--------------------------
Patching file xen/arch/x86/hvm/svm/svm.c using Plan A...
Hunk #1 succeeded at 942.
Hunk #2 succeeded at 2233.
Hunk #3 succeeded at 2283.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- xen/arch/x86/hvm/vmx/vmx.c.orig
|+++ xen/arch/x86/hvm/vmx/vmx.c
--------------------------
Patching file xen/arch/x86/hvm/vmx/vmx.c using Plan A...
Hunk #1 succeeded at 1184 (offset 62 lines).
Hunk #2 succeeded at 2446 (offset -164 lines).
Hunk #3 succeeded at 2736 (offset 62 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- xen/include/asm-x86/hvm/hvm.h.orig
|+++ xen/include/asm-x86/hvm/hvm.h
--------------------------
Patching file xen/include/asm-x86/hvm/hvm.h using Plan A...
Hunk #1 succeeded at 385 (offset -4 lines).
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-7835
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-7835
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-CVE-2015-7835,v 1.1 2015/10/29 21:59:16 bouyer Exp $
|
|Patch for CVE-2015-7835 aka XSA-148 based on
|http://xenbits.xenproject.org/xsa/xsa148-4.4.patch
|
|--- xen/arch/x86/mm.c.orig	2014-09-02 08:22:57.000000000 +0200
|+++ xen/arch/x86/mm.c	2015-10-29 22:27:31.000000000 +0100
--------------------------
Patching file xen/arch/x86/mm.c using Plan A...
Hunk #1 succeeded at 169.
Hunk #2 succeeded at 1983.
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-7969
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-7969
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-CVE-2015-7969,v 1.1 2015/10/29 21:59:16 bouyer Exp $
|
|Patch for CVE-2015-7869 aka XSA-149 + XSA-151 based on
|http://xenbits.xenproject.org/xsa/xsa149.patch
|http://xenbits.xenproject.org/xsa/xsa151.patch
|
|--- xen/common/domain.c.orig	2014-09-02 08:22:57.000000000 +0200
|+++ xen/common/domain.c	2015-10-29 22:29:21.000000000 +0100
--------------------------
Patching file xen/common/domain.c using Plan A...
Hunk #1 succeeded at 685.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- xen/common/xenoprof.c.orig	2014-09-02 08:22:57.000000000 +0200
|+++ xen/common/xenoprof.c	2015-10-29 22:29:35.000000000 +0100
--------------------------
Patching file xen/common/xenoprof.c using Plan A...
Hunk #1 succeeded at 239.
Hunk #2 succeeded at 287.
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-7971
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-7971
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-CVE-2015-7971,v 1.1 2015/10/29 21:59:16 bouyer Exp $
|
|Patch for CVE-2015-7971 aka XSA-152, based on
|http://xenbits.xenproject.org/xsa/xsa152.patch
|
|--- xen/common/xenoprof.c.orig
|+++ xen/common/xenoprof.c
--------------------------
Patching file xen/common/xenoprof.c using Plan A...
Hunk #1 succeeded at 673 (offset -3 lines).
Hunk #2 succeeded at 902 (offset -3 lines).
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-8339
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-8339
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-CVE-2015-8339,v 1.1 2016/01/07 17:53:58 bouyer Exp $
|
|Patch for CVE-2015-8339 and CVE-2015-8340 aka XSA-159, based on
|http://xenbits.xenproject.org/xsa/xsa159.patch
|
|--- xen/common/memory.c.orig
|+++ xen/common/memory.c
--------------------------
Patching file xen/common/memory.c using Plan A...
Hunk #1 succeeded at 286 (offset -48 lines).
Hunk #2 succeeded at 558 (offset -14 lines).
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-8555
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/patches/patch-CVE-2015-8555
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-CVE-2015-8555,v 1.1 2016/01/07 17:53:58 bouyer Exp $
|
|Patch for CVE-2015-8555 aka XSA-165, based on
|http://xenbits.xenproject.org/xsa/xsa165-4.3.patch
|
|--- 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 836 (offset 106 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- xen/arch/x86/i387.c.orig
|+++ xen/arch/x86/i387.c
--------------------------
Patching file xen/arch/x86/i387.c using Plan A...
Hunk #1 succeeded at 17.
Hunk #2 succeeded at 245 (offset 4 lines).
Hunk #3 succeeded at 307 (offset 4 lines).
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-Config.mk
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/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 2013/06/13 21:49:59 joerg Exp $
|
|--- Config.mk.orig	2012-12-18 12:54:16.000000000 +0000
|+++ Config.mk
--------------------------
Patching file Config.mk using Plan A...
Hunk #1 succeeded at 26 (offset 10 lines).
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-166
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-166
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-XSA-166,v 1.1 2016/01/07 17:53:58 bouyer Exp $
|
|Patch for XSA-166, based on
|http://xenbits.xenproject.org/xsa/xsa166-4.3.patch
|
|--- 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 320 (offset -22 lines).
Hunk #2 succeeded at 328 (offset -22 lines).
Hunk #3 succeeded at 339 (offset -22 lines).
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-182
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-182
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-XSA-182,v 1.1 2016/07/26 15:38:00 bouyer Exp $
|
|backported from:
|
|From 798c1498f764bfaa7b0b955bab40b01b0610d372 Mon Sep 17 00:00:00 2001
|From: Andrew Cooper <andrew.cooper3@citrix.com>
|Date: Mon, 11 Jul 2016 14:32:03 +0100
|Subject: [PATCH] x86/pv: Remove unsafe bits from the mod_l?_entry() fastpath
|
|All changes in writeability and cacheability must go through full
|re-validation.
|
|Rework the logic as a whitelist, to make it clearer to follow.
|
|This is XSA-182
|
|--- xen/arch/x86/mm.c.orig	2016-07-26 16:33:46.000000000 +0200
|+++ xen/arch/x86/mm.c	2016-07-26 16:37:14.000000000 +0200
--------------------------
Patching file xen/arch/x86/mm.c using Plan A...
Hunk #1 succeeded at 1860.
Hunk #2 succeeded at 1908.
Hunk #3 succeeded at 1990.
Hunk #4 succeeded at 2056.
Hunk #5 succeeded at 2126.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|
|--- xen/include/asm-x86/page.h.orig	2014-09-02 08:22:57.000000000 +0200
|+++ xen/include/asm-x86/page.h	2016-07-26 16:39:51.000000000 +0200
--------------------------
Patching file xen/include/asm-x86/page.h using Plan A...
Hunk #1 succeeded at 332.
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-185
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-185
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-XSA-185,v 1.1 2016/09/08 15:41:01 bouyer Exp $
|
|From 30aba4992b18245c436f16df7326a16c01a51570 Mon Sep 17 00:00:00 2001
|From: Jan Beulich <jbeulich@suse.com>
|Date: Mon, 8 Aug 2016 10:58:12 +0100
|Subject: x86/32on64: don't allow recursive page tables from L3
|
|L3 entries are special in PAE mode, and hence can't reasonably be used
|for setting up recursive (and hence linear) page table mappings. Since
|abuse is possible when the guest in fact gets run on 4-level page
|tables, this needs to be excluded explicitly.
|
|This is XSA-185.
|
|Reported-by: Jérémie Boutoille <jboutoille@ext.quarkslab.com>
|Reported-by: 栾尚聪(好风) <shangcong.lsc@alibaba-inc.com>
|Signed-off-by: Jan Beulich <jbeulich@suse.com>
|Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
|---
| xen/arch/x86/mm.c | 4 +++-
| 1 file changed, 3 insertions(+), 1 deletion(-)
|
|diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
|index 109b8be..69b8b8d 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 1048 (offset -74 lines).
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-187-1
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-187-1
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-XSA-187-1,v 1.1 2016/09/08 15:41:01 bouyer Exp $
|
|From: Andrew Cooper <andrew.cooper3@citrix.com>
|Subject: x86/shadow: Avoid overflowing sh_ctxt->seg_reg[]
|
|hvm_get_seg_reg() does not perform a range check on its input segment, calls
|hvm_get_segment_register() and writes straight into sh_ctxt->seg_reg[].
|
|x86_seg_none is outside the bounds of sh_ctxt->seg_reg[], and will hit a BUG()
|in {vmx,svm}_get_segment_register().
|
|HVM guests running with shadow paging can end up performing a virtual to
|linear translation with x86_seg_none.  This is used for addresses which are
|already linear.  However, none of this is a legitimate pagetable update, so
|fail the emulation in such a case.
|
|This is XSA-187
|
|Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
|Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
|Reviewed-by: Tim Deegan <tim@xen.org>
|
|--- 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 127 (offset -13 lines).
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-187-2
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-187-2
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-XSA-187-2,v 1.1 2016/09/08 15:41:01 bouyer Exp $
|
|From: Andrew Cooper <andrew.cooper3@citrix.com>
|Subject: x86/segment: Bounds check accesses to emulation ctxt->seg_reg[]
|
|HVM HAP codepaths have space for all segment registers in the seg_reg[]
|cache (with x86_seg_none still risking an array overrun), while the shadow
|codepaths only have space for the user segments.
|
|Range check the input segment of *_get_seg_reg() against the size of the array
|used to cache the results, to avoid overruns in the case that the callers
|don't filter their input suitably.
|
|Subsume the is_x86_user_segment(seg) checks from the shadow code, which were
|an incomplete attempt at range checking, and are now superceeded.  Make
|hvm_get_seg_reg() static, as it is not used outside of shadow/common.c
|
|No functional change, but far easier to reason that no overflow is possible.
|
|Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
|Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
|Acked-by: Tim Deegan <tim@xen.org>
|Acked-by: Jan Beulich <jbeulich@suse.com>
|
|--- 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 110 (offset -15 lines).
Hunk #2 succeeded at 139 (offset -15 lines).
Hunk #3 succeeded at 243 (offset -15 lines).
Hunk #4 succeeded at 270 (offset -15 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- xen/include/asm-x86/hvm/emulate.h.orig	2014-09-02 08:22:57.000000000 +0200
|+++ xen/include/asm-x86/hvm/emulate.h	2016-09-08 15:57:32.000000000 +0200
--------------------------
Patching file xen/include/asm-x86/hvm/emulate.h using Plan A...
Hunk #1 succeeded at 13.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- xen/arch/x86/hvm/emulate.c.orig	2014-09-02 08:22:57.000000000 +0200
|+++ xen/arch/x86/hvm/emulate.c	2016-09-08 16:01:31.000000000 +0200
--------------------------
Patching file xen/arch/x86/hvm/emulate.c using Plan A...
Hunk #1 succeeded at 390.
Hunk #2 succeeded at 779.
Hunk #3 succeeded at 796.
Hunk #4 succeeded at 1139.
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-191
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-191
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-XSA-191,v 1.1 2016/11/22 20:55:29 bouyer Exp $
|
|backported from:
|
|From: Andrew Cooper <andrew.cooper3@citrix.com>
|Subject: x86/hvm: Fix the handling of non-present segments
|
|In 32bit, the data segments may be NULL to indicate that the segment is
|ineligible for use.  In both 32bit and 64bit, the LDT selector may be NULL to
|indicate that the entire LDT is ineligible for use.  However, nothing in Xen
|actually checks for this condition when performing other segmentation
|checks.  (Note however that limit and writeability checks are correctly
|performed).
|
|Neither Intel nor AMD specify the exact behaviour of loading a NULL segment.
|Experimentally, AMD zeroes all attributes but leaves the base and limit
|unmodified.  Intel zeroes the base, sets the limit to 0xfffffff and resets the
|attributes to just .G and .D/B.
|
|The use of the segment information in the VMCB/VMCS is equivalent to a native
|pipeline interacting with the segment cache.  The present bit can therefore
|have a subtly different meaning, and it is now cooked to uniformly indicate
|whether the segment is usable or not.
|
|GDTR and IDTR don't have access rights like the other segments, but for
|consistency, they are treated as being present so no special casing is needed
|elsewhere in the segmentation logic.
|
|AMD hardware does not consider the present bit for %cs and %tr, and will
|function as if they were present.  They are therefore unconditionally set to
|present when reading information from the VMCB, to maintain the new meaning of
|usability.
|
|Intel hardware has a separate unusable bit in the VMCS segment attributes.
|This bit is inverted and stored in the present field, so the hvm code can work
|with architecturally-common state.
|
|This is XSA-191.
|
|Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
|Reviewed-by: Jan Beulich <jbeulich@suse.com>
|
|--- xen/arch/x86/hvm/hvm.c.orig	2016-11-22 15:03:34.000000000 +0100
|+++ xen/arch/x86/hvm/hvm.c	2016-11-22 15:15:51.000000000 +0100
--------------------------
Patching file xen/arch/x86/hvm/hvm.c using Plan A...
Hunk #1 succeeded at 1921.
Hunk #2 succeeded at 2109.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- xen/arch/x86/hvm/svm/svm.c.orig	2016-11-22 15:03:33.000000000 +0100
|+++ xen/arch/x86/hvm/svm/svm.c	2016-11-22 15:15:51.000000000 +0100
--------------------------
Patching file xen/arch/x86/hvm/svm/svm.c using Plan A...
Hunk #1 succeeded at 517.
Hunk #2 succeeded at 551.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- xen/arch/x86/hvm/vmx/vmx.c.orig	2016-11-22 15:03:33.000000000 +0100
|+++ xen/arch/x86/hvm/vmx/vmx.c	2016-11-22 15:15:51.000000000 +0100
--------------------------
Patching file xen/arch/x86/hvm/vmx/vmx.c using Plan A...
Hunk #1 succeeded at 809.
Hunk #2 succeeded at 894.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- xen/arch/x86/x86_emulate/x86_emulate.c.orig	2016-11-22 15:03:34.000000000 +0100
|+++ xen/arch/x86/x86_emulate/x86_emulate.c	2016-11-22 15:15:51.000000000 +0100
--------------------------
Patching file xen/arch/x86/x86_emulate/x86_emulate.c using Plan A...
Hunk #1 succeeded at 1136.
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-192
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-192
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-XSA-192,v 1.1 2016/11/22 20:55:29 bouyer Exp $
|
|From: Jan Beulich <jbeulich@suse.com>
|Subject: x86/HVM: don't load LDTR with VM86 mode attrs during task switch
|
|Just like TR, LDTR is purely a protected mode facility and hence needs
|to be loaded accordingly. Also move its loading to where it
|architecurally belongs.
|
|This is XSA-192.
|
|Signed-off-by: Jan Beulich <jbeulich@suse.com>
|Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
|Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
|
|--- xen/arch/x86/hvm/hvm.c.orig	2016-11-22 15:15:51.000000000 +0100
|+++ xen/arch/x86/hvm/hvm.c	2016-11-22 15:29:02.000000000 +0100
--------------------------
Patching file xen/arch/x86/hvm/hvm.c using Plan A...
Hunk #1 succeeded at 2072.
Hunk #2 succeeded at 2331.
Hunk #3 succeeded at 2355.
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-195
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-195
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-XSA-195,v 1.1 2016/11/22 20:55:29 bouyer Exp $
|
|backported from:
|
|From: Jan Beulich <jbeulich@suse.com>
|Subject: x86emul: fix huge bit offset handling
|
|We must never chop off the high 32 bits.
|
|This is XSA-195.
|
|Reported-by: George Dunlap <george.dunlap@citrix.com>
|Signed-off-by: Jan Beulich <jbeulich@suse.com>
|Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
|
|--- xen/arch/x86/x86_emulate/x86_emulate.c.orig	2016-11-22 15:15:51.000000000 +0100
|+++ xen/arch/x86/x86_emulate/x86_emulate.c	2016-11-22 16:02:09.000000000 +0100
--------------------------
Patching file xen/arch/x86/x86_emulate/x86_emulate.c using Plan A...
Hunk #1 succeeded at 1756.
Hunk #2 succeeded at 1773.
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-200
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-200
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-XSA-200,v 1.1 2016/12/20 10:22:28 bouyer Exp $
|
|From: Jan Beulich <jbeulich@suse.com>
|Subject: x86emul: CMPXCHG8B ignores operand size prefix
|
|Otherwise besides mis-handling the instruction, the comparison failure
|case would result in uninitialized stack data being handed back to the
|guest in rDX:rAX (32 bits leaked for 32-bit guests, 96 bits for 64-bit
|ones).
|
|This is XSA-200.
|
|Signed-off-by: Jan Beulich <jbeulich@suse.com>
|
|--- tools/tests/x86_emulator/test_x86_emulator.c.orig
|+++ tools/tests/x86_emulator/test_x86_emulator.c
--------------------------
Patching file tools/tests/x86_emulator/test_x86_emulator.c using Plan A...
Hunk #1 succeeded at 396 (offset -33 lines).
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- xen/arch/x86/x86_emulate/x86_emulate.c.orig
|+++ xen/arch/x86/x86_emulate/x86_emulate.c
--------------------------
Patching file xen/arch/x86/x86_emulate/x86_emulate.c using Plan A...
Hunk #1 succeeded at 4498.
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-202
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-202
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-XSA-202,v 1.1 2016/12/21 15:35:44 bouyer Exp $
|
|From: Jan Beulich <jbeulich@suse.com>
|Subject: x86: force EFLAGS.IF on when exiting to PV guests
|
|Guest kernels modifying instructions in the process of being emulated
|for another of their vCPU-s may effect EFLAGS.IF to be cleared upon
|next exiting to guest context, by converting the being emulated
|instruction to CLI (at the right point in time). Prevent any such bad
|effects by always forcing EFLAGS.IF on. And to cover hypothetical other
|similar issues, also force EFLAGS.{IOPL,NT,VM} to zero.
|
|This is XSA-202.
|
|Signed-off-by: Jan Beulich <jbeulich@suse.com>
|
| 
|--- xen/arch/x86/x86_64/entry.S.orig
|+++ xen/arch/x86/x86_64/entry.S
--------------------------
Patching file xen/arch/x86/x86_64/entry.S using Plan A...
Hunk #1 succeeded at 41.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- xen/arch/x86/x86_64/compat/entry.S.orig	2014-09-02 08:22:57.000000000 +0200
|+++ xen/arch/x86/x86_64/compat/entry.S	2016-12-21 13:23:21.000000000 +0100
--------------------------
Patching file xen/arch/x86/x86_64/compat/entry.S using Plan A...
Hunk #1 succeeded at 173.
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-204
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/patches/patch-XSA-204
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-XSA-204,v 1.1 2016/12/20 10:22:28 bouyer Exp $
|
|From: Andrew Cooper <andrew.cooper3@citrix.com>
|Date: Sun, 18 Dec 2016 15:42:59 +0000
|Subject: [PATCH] x86/emul: Correct the handling of eflags with SYSCALL
|
|A singlestep #DB is determined by the resulting eflags value from the
|execution of SYSCALL, not the original eflags value.
|
|By using the original eflags value, we negate the guest kernels attempt to
|protect itself from a privilege escalation by masking TF.
|
|Introduce a tf boolean and have the SYSCALL emulation recalculate it
|after the instruction is complete.
|
|This is XSA-204
|
|Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
|Reviewed-by: Jan Beulich <jbeulich@suse.com>
|---
| xen/arch/x86/x86_emulate/x86_emulate.c | 23 ++++++++++++++++++++---
| 1 file changed, 20 insertions(+), 3 deletions(-)
|
|diff --git a/xen/arch/x86/x86_emulate/x86_emulate.c b/xen/arch/x86/x86_emulate/x86_emulate.c
|index 0c43fe1..f675dc9 100644
|--- xen/arch/x86/x86_emulate/x86_emulate.c.orig	2016-12-19 23:22:20.000000000 +0100
|+++ xen/arch/x86/x86_emulate/x86_emulate.c	2016-12-19 23:22:38.000000000 +0100
--------------------------
Patching file xen/arch/x86/x86_emulate/x86_emulate.c using Plan A...
Hunk #1 succeeded at 1348.
Hunk #2 succeeded at 3678 (offset -2 lines).
Hunk #3 succeeded at 3864 (offset -2 lines).
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-xen_Makefile
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/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 2013/06/13 21:49:59 joerg Exp $
|
|--- xen/Makefile.orig	2013-04-23 16:42:55.000000000 +0000
|+++ xen/Makefile
--------------------------
Patching file xen/Makefile using Plan A...
Hunk #1 succeeded at 118.
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-xen_arch_x86_Rules.mk
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/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 2013/06/13 21:49:59 joerg Exp $
|
|--- xen/arch/x86/Rules.mk.orig	2013-03-25 13:28:19.000000000 +0000
|+++ xen/arch/x86/Rules.mk
--------------------------
Patching file xen/arch/x86/Rules.mk using Plan A...
Hunk #1 succeeded at 28 (offset 7 lines).
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-xen_arch_x86_hvm_hvm.c
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/patches/patch-xen_arch_x86_hvm_hvm.c
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-xen_arch_x86_hvm_hvm.c,v 1.1 2014/10/01 17:34:54 bouyer Exp $
|
|x86/HVM: properly bound x2APIC MSR range
|
|While the write path change appears to be purely cosmetic (but still
|gets done here for consistency), the read side mistake permitted
|accesses beyond the virtual APIC page.
|
|Note that while this isn't fully in line with the specification
|(digesting MSRs 0x800-0xBFF for the x2APIC), this is the minimal
|possible fix addressing the security issue and getting x2APIC related
|code into a consistent shape (elsewhere a 256 rather than 1024 wide
|window is being used too). This will be dealt with subsequently.
|
|This is XSA-108.
|
|Signed-off-by: Jan Beulich <jbeulich@suse.com>
|
|--- 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 2887 (offset -1493 lines).
Hunk #2 succeeded at 4500 (offset -6 lines).
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-xen_arch_x86_mm_shadow_common.c
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/patches/patch-xen_arch_x86_mm_shadow_common.c
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-xen_arch_x86_mm_shadow_common.c,v 1.1 2014/09/26 10:39:31 bouyer Exp $
|
|patch for XSA-104/CVE-2014-7154, from Xen Security Advisory
|
|--- xen/arch/x86/mm/shadow/common.c.orig	2014-09-02 08:22:57.000000000 +0200
|+++ xen/arch/x86/mm/shadow/common.c	2014-09-26 11:18:02.000000000 +0200
--------------------------
Patching file xen/arch/x86/mm/shadow/common.c using Plan A...
Hunk #1 succeeded at 3608 (offset 7 lines).
Hunk #2 succeeded at 3618 (offset 7 lines).
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-xen_arch_x86_x86_emulate_x86_emulate.c
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/patches/patch-xen_arch_x86_x86_emulate_x86_emulate.c
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-xen_arch_x86_x86_emulate_x86_emulate.c,v 1.1 2014/09/26 10:39:31 bouyer Exp $
|
|patch for XSA-105/CVE-2014-7155 and XSA-106/CVE-2014-7156,
|from Xen Security Advisory
|
|--- xen/arch/x86/x86_emulate/x86_emulate.c.orig	2014-09-26 11:53:50.000000000 +0200
|+++ xen/arch/x86/x86_emulate/x86_emulate.c	2014-09-26 11:53:43.000000000 +0200
--------------------------
Patching file xen/arch/x86/x86_emulate/x86_emulate.c using Plan A...
Hunk #1 succeeded at 2642 (offset 26 lines).
Hunk #2 succeeded at 3323 (offset 26 lines).
Hunk #3 succeeded at 3722 (offset -1 lines).
Hunk #4 succeeded at 3778 (offset 26 lines).
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-xen_common_spinlock.c
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/patches/patch-xen_common_spinlock.c
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-xen_common_spinlock.c,v 1.1 2014/12/30 08:15:01 spz Exp $
|
|from XSA-114:
|switch to write-biased r/w locks
|
|This is to improve fairness: A permanent flow of read acquires can
|otherwise lock out eventual writers indefinitely.
|
|This is XSA-114 / CVE-2014-9065.
|
|--- xen/common/spinlock.c.orig	2014-09-02 06:22:57.000000000 +0000
|+++ xen/common/spinlock.c
--------------------------
Patching file xen/common/spinlock.c using Plan A...
Hunk #1 succeeded at 271.
Hunk #2 succeeded at 423.
Hunk #3 succeeded at 437.
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-xen_common_symbols.c
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/patches/patch-xen_common_symbols.c
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-xen_common_symbols.c,v 1.1 2016/09/12 13:22:39 maya Exp $
|
|upstream build fix for GCC5
|https://lists.xenproject.org/archives/html/xen-devel/2015-03/msg01687.html
|
|--- xen/common/symbols.c.orig	2014-09-02 06:22:57.000000000 +0000
|+++ xen/common/symbols.c
--------------------------
Patching file xen/common/symbols.c using Plan A...
Hunk #1 succeeded at 19.
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-xen_drivers_passthrough_vtd_x86_ats.c
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/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 2015/09/14 13:36:29 joerg Exp $
|
|--- xen/drivers/passthrough/vtd/x86/ats.c.orig	2014-09-02 06:22:57.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 134.
Hunk #2 succeeded at 146.
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-xen_include_asm-arm_spinlock.h
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/patches/patch-xen_include_asm-arm_spinlock.h
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-xen_include_asm-arm_spinlock.h,v 1.1 2014/12/30 08:15:01 spz Exp $
|
|from XSA-114:
|switch to write-biased r/w locks
|
|This is to improve fairness: A permanent flow of read acquires can
|otherwise lock out eventual writers indefinitely.
|
|This is XSA-114 / CVE-2014-9065.
|
|--- xen/include/asm-arm/spinlock.h.orig	2014-09-02 06:22:57.000000000 +0000
|+++ xen/include/asm-arm/spinlock.h
--------------------------
Patching file xen/include/asm-arm/spinlock.h using Plan A...
Hunk #1 succeeded at 55.
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-xen_include_asm-x86_atomic.h
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/patches/patch-xen_include_asm-x86_atomic.h
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-xen_include_asm-x86_atomic.h,v 1.1 2015/03/18 15:05:51 joerg Exp $
|
|read_atomic() is used in the condition part of while() loops, so don't
|use break here.
|
|--- xen/include/asm-x86/atomic.h.orig	2015-03-17 23:41:49.000000000 +0000
|+++ xen/include/asm-x86/atomic.h
--------------------------
Patching file xen/include/asm-x86/atomic.h using Plan A...
Hunk #1 succeeded at 46.
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-xen_include_asm-x86_spinlock.h
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/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 2014/12/30 08:15:01 spz Exp $
|
|from XSA-114:
|switch to write-biased r/w locks
|
|This is to improve fairness: A permanent flow of read acquires can
|otherwise lock out eventual writers indefinitely.
|
|This is XSA-114 / CVE-2014-9065.
|
|--- xen/include/asm-x86/spinlock.h.orig	2014-09-02 06:22:57.000000000 +0000
|+++ xen/include/asm-x86/spinlock.h
--------------------------
Patching file xen/include/asm-x86/spinlock.h using Plan A...
Hunk #1 succeeded at 31.
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-xen_include_xen_lib.h
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/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 2013/06/13 21:49:59 joerg Exp $
|
|--- xen/include/xen/lib.h.orig	2013-06-13 19:59:04.000000000 +0000
|+++ xen/include/xen/lib.h
--------------------------
Patching file xen/include/xen/lib.h using Plan A...
Hunk #1 succeeded at 42.
done
=> Verifying /data/pkgsrc/sysutils/xenkernel42/patches/patch-xen_include_xen_spinlock.h
=> Applying pkgsrc patch /data/pkgsrc/sysutils/xenkernel42/patches/patch-xen_include_xen_spinlock.h
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|$NetBSD: patch-xen_include_xen_spinlock.h,v 1.1 2014/12/30 08:15:01 spz Exp $
|
|from XSA-114:
|switch to write-biased r/w locks
|
|This is to improve fairness: A permanent flow of read acquires can
|otherwise lock out eventual writers indefinitely.
|
|This is XSA-114 / CVE-2014-9065.
|
|--- xen/include/xen/spinlock.h.orig	2014-09-02 06:22:57.000000000 +0000
|+++ xen/include/xen/spinlock.h
--------------------------
Patching file xen/include/xen/spinlock.h using Plan A...
Hunk #1 succeeded at 141.
done
===> Creating toolchain wrappers for xenkernel42-4.2.5nb16